ldc compiled binaries seg faults

David Nadlinger code at klickverbot.at
Thu Oct 17 10:44:45 PDT 2013

Hi Alexandr,

On Mon, Oct 7, 2013 at 5:35 PM, Alexandr Druzhinin <drug2004 at 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

> 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

> 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. ;)


More information about the digitalmars-d-ldc mailing list