I have a simple project https://github.com/drug007/geoviewer.
If I build it using
dub build --compiler=dmd
it compiles and works as expected
but if I do
dub build --compiler=ldmd2
it compiles but crashes with core dumped

OS:
Linux drug 3.2.0-54-generic #82-Ubuntu SMP Tue Sep 10 20:08:42 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
ldc:
LDC - the LLVM D compiler (dd2a2a):
  based on DMD v2.063.2 and LLVM 3.2
  Default target: x86_64-pc-linux-gnu
  Host CPU: k8-sse3

I have no glue how to build working binaries with ldc - I can't parse core dumpings to find it out (yet)

Could someone to help with it? Where and what should I do to find answer why binary crashes?

On Monday, 7 October 2013 at 11:40:39 UTC, Alexandr Druzhinin wrote:
> Could someone to help with it? Where and what should I do to find answer why binary crashes?

The basic idea is to launch the executable in a debugger (gdb myprogram, then 'r') and see where it crashes. Without knowing what kind of problem this is, it's hard to get more specific.

I tried to have a look at the issue myself, but the program wouldn't build (fresh Git clone, dub build):

---
Checking dependencies in '/home/aule/Build/Source/geoviewer'
Package gl3n (configuration "library") defines no import paths, use {"importPaths": [...]} or the default package directory structure to fix this.
Package derelict (configuration "library") defines no import paths, use {"importPaths": [...]} or the default package directory structure to fix this.
Package glamour (configuration "Derelict3-gl3n-SDLImage") defines no import paths, use {"importPaths": [...]} or the default package directory structure to fix this.
Building configuration "application", build type debug
Running /home/aule/Build/Work/ldc2-llvm3.3-release-multilib/bin/ldmd2...
/home/aule/.dub/packages/arsd-master/arsd/netman.d(535): Warning: else is dangling, add { } after condition at /home/aule/.dub/packages/arsd-master/arsd/netman.d(532)
/home/aule/.dub/packages/arsd-master/arsd/netman.d(505): Error: module date is in file 'std/date.d' which cannot be read
---

std.date hasn't been around since 2012…

David

07.10.2013 20:30, David Nadlinger пишет:
>
> The basic idea is to launch the executable in a debugger (gdb myprogram,
> then 'r') and see where it crashes. Without knowing what kind of problem
> this is, it's hard to get more specific.
>
> I tried to have a look at the issue myself, but the program wouldn't
> build (fresh Git clone, dub build):
>
> ---
> Checking dependencies in '/home/aule/Build/Source/geoviewer'
> Package gl3n (configuration "library") defines no import paths, use
> {"importPaths": [...]} or the default package directory structure to fix
> this.
> Package derelict (configuration "library") defines no import paths, use
> {"importPaths": [...]} or the default package directory structure to fix
> this.
> Package glamour (configuration "Derelict3-gl3n-SDLImage") defines no
> import paths, use {"importPaths": [...]} or the default package
> directory structure to fix this.
> Building configuration "application", build type debug
> Running /home/aule/Build/Work/ldc2-llvm3.3-release-multilib/bin/ldmd2...
> /home/aule/.dub/packages/arsd-master/arsd/netman.d(535): Warning: else
> is dangling, add { } after condition at
> /home/aule/.dub/packages/arsd-master/arsd/netman.d(532)
> /home/aule/.dub/packages/arsd-master/arsd/netman.d(505): Error: module
> date is in file 'std/date.d' which cannot be read
> ---
>
> std.date hasn't been around since 2012…
>
> David
Thanks for reply!
Yes, compilation failed because there are outdated files in Adam D. Ruppe dub package I use - I removed it manually (if it matters I use only two files - characterencodings.d and dom.d).
I tried to use gdb, I've used it just several times, so let me ask some question if you don't mind:

(gdb) r bin/osm-no-label.xml
Starting program: /home/drug/workspace/geoviewer/bin/geoviewer bin/osm-no-label.xml
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0000000000422a66 in frontend.FrontEnd.__ctor() (this=<optimized out>,
    width=<optimized out>, height=<optimized out>) at frontend.d:45
45			DerelictSDL2.load();

Does it means that the program crashes while derelict loader tries to load SDL2 lib? Can I do to investigate it more detaily? I set a breakpoint on this line but if I do step the application crashes immediatly so I can't to step in DerelictSDL2.load() function (perhaps I have code for it)
Sorry for dumb questions.

Hi Alexandr,

On Mon, Oct 7, 2013 at 5:35 PM, Alexandr Druzhinin <drug2004@bk.ru> wrote:
> Yes, compilation failed because there are outdated files in Adam D. Ruppe dub package I use - I removed it manually (if it matters I use only two files - characterencodings.d and dom.d).

I tried to build the project from source some days ago again, but it wouldn't work due to some bugs in the PQ header files, and I didn't really have the time to figure out what I could remove to make it work.

> 0x0000000000422a66 in frontend.FrontEnd.__ctor() (this=<optimized out>,
>     width=<optimized out>, height=<optimized out>) at frontend.d:45
> 45                      DerelictSDL2.load();
>
> Does it means that the program crashes while derelict loader tries to load SDL2 lib?

Well, it means that there was some sort of invalid memory access in the frontend.FrontEnd constructor. As your program seems to be built with optimizations on, location info is usually not perfectly reliable, and the issue might include any of the called functions. It is unlikely that it is actually in DerelictSDL2.load(), but it could be.

> Can I do to investigate it more detaily?
The easiest way to figure out what's going on here would probably to reduce the test case, i.e. selectively remove parts of the program until the crash disappears. With a smaller program that still crashes in hand, it is usually much easier to see what the issue for this could be, especially if one is not really fluent in reading LLVM IR and assembly code.

You can also try to run "disas" in GDB after the crash happened and see which instruction actually causes the segfault. If the function in question (i.e. the FrontEnd constructor) is short, it can be fairly easy to see what is going on.

> Sorry for dumb questions.

No worries – debugging compiler issues is an art that takes some time to pick up. ;)

Cheers,
David

On Thu, Oct 17, 2013 at 7:44 PM, David Nadlinger <code@klickverbot.at> wrote:
> As your program seems to be built
> with optimizations on, location info is usually not perfectly
> reliable, and the issue might include any of the called functions. It
> is unlikely that it is actually in DerelictSDL2.load(), but it could
> be.

I just had a look at the source, and DerelictSDL2.load() is actually the first line in the constructor, so the issue might have nothing to do with DerelictSDL2 at all. The easiest way to see this would be to try flipping the order of the calls in the constructor.

David

18.10.2013 00:46, David Nadlinger пишет:
> On Thu, Oct 17, 2013 at 7:44 PM, David Nadlinger <code@klickverbot.at> wrote:
>> As your program seems to be built
>> with optimizations on, location info is usually not perfectly
>> reliable, and the issue might include any of the called functions. It
>> is unlikely that it is actually in DerelictSDL2.load(), but it could
>> be.
>
> I just had a look at the source, and DerelictSDL2.load() is actually
> the first line in the constructor, so the issue might have nothing to
> do with DerelictSDL2 at all. The easiest way to see this would be to
> try flipping the order of the calls in the constructor.
>
> David
>
I have managed solve the problem. I'm very ashamed but the problem was that I used shared version of phobos. With static version there are no crashes and all works fine (both 0.11.0 and 0.12.0 versions). I just experimented with shared version of phobos and forget about it, sorry again for inconvenience and thanks for reply!

On Fri, Oct 18, 2013 at 3:19 AM, Alexandr Druzhinin <drug2004@bk.ru> wrote:
> I used shared version of phobos. With static version there are no crashes and all works fine (both 0.11.0 and 0.12.0 versions).

Yep, you can't expect the shared library builds to work at all right now if your program uses garbage collected memory. We will probably address this once the 2.064 frontend is merged, which shuffles the support code in druntime around again quite a bit.

David