www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - ldc compiled binaries seg faults

reply Alexandr Druzhinin <drug2004 bk.ru> writes:
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:

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)
Oct 06 2013
parent reply Alexandr Druzhinin <drug2004 bk.ru> writes:
Could someone to help with it? Where and what should I do to find answer 
why binary crashes?
Oct 07 2013
parent reply "David Nadlinger" <code klickverbot.at> writes:
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
Oct 07 2013
parent reply Alexandr Druzhinin <drug2004 bk.ru> writes:
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.
Oct 07 2013
next sibling parent David Nadlinger <code klickverbot.at> writes:
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=3D<optimized out>,
     width=3D<optimized out>, height=3D<optimized out>) at frontend.d:45
 45                      DerelictSDL2.load();

 Does it means that the program crashes while derelict loader tries to loa=
d
 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 =E2=80=93 debugging compiler issues is an art that takes some ti= me to pick up. ;) Cheers, David
Oct 17 2013
prev sibling parent reply David Nadlinger <code klickverbot.at> writes:
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
Oct 17 2013
parent reply Alexandr Druzhinin <drug2004 bk.ru> writes:
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!
Oct 17 2013
parent David Nadlinger <code klickverbot.at> writes:
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
Oct 17 2013