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