www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 758] New: Segmentation fault when compiling.

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=758

           Summary: Segmentation fault when compiling.
           Product: D
           Version: 0.178
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: link-failure
          Severity: major
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: quartz13163 distanthumans.info


Segmentation occurs when compiling with a large amount of source files passed
to dmd. When I compile a tiny derelict sample program bud creates the necessary
parameters to the call to dmd. As you problably know bud scans the import
depedencies creating a list of d files to compile. The list can get fairly
large, which makes dmd crash.

Here is an example:

 /home/wdevore/D2/dmd/bin/dmd -c -version=Posix -L-ldl -w -op
-I"/home/wdevore/D2/dmd/src/ext/" -I"/home/wdevore/D2/dmd/src/phobos/"
-I"/home/wdevore/D2/test/" -I"/home/wdevore/D2/dmd/src/ext/derelict/opengl/"
-I"/home/wdevore/D2/dmd/src/ext/derelict/util/"
-I"/home/wdevore/D2/dmd/src/ext/derelict/sdl/" test.d
/home/wdevore/D2/dmd/src/ext/derelict/opengl/gl.d
/home/wdevore/D2/dmd/src/ext/derelict/opengl/gltypes.d
/home/wdevore/D2/dmd/src/ext/derelict/opengl/glfuncs.d
/home/wdevore/D2/dmd/src/ext/derelict/util/loader.d
/home/wdevore/D2/dmd/src/ext/derelict/util/exception.d
/home/wdevore/D2/dmd/src/ext/derelict/opengl/gl12.d
/home/wdevore/D2/dmd/src/ext/derelict/opengl/gl13.d
/home/wdevore/D2/dmd/src/ext/derelict/opengl/gl14.d
/home/wdevore/D2/dmd/src/ext/derelict/opengl/gl15.d
/home/wdevore/D2/dmd/src/ext/derelict/opengl/gl20.d
/home/wdevore/D2/dmd/src/ext/derelict/opengl/gl21.d
/home/wdevore/D2/dmd/src/ext/derelict/opengl/glx.d
/home/wdevore/D2/dmd/src/ext/derelict/sdl/sdl.d
/home/wdevore/D2/dmd/src/ext/derelict/sdl/active.d
/home/wdevore/D2/dmd/src/ext/derelict/sdl/types.d
/home/wdevore/D2/dmd/src/ext/derelict/sdl/audio.d
/home/wdevore/D2/dmd/src/ext/derelict/sdl/rwops.d
/home/wdevore/D2/dmd/src/ext/derelict/sdl/byteorder.d
/home/wdevore/D2/dmd/src/ext/derelict/sdl/cdrom.d
/home/wdevore/D2/dmd/src/ext/derelict/sdl/cpuinfo.d
/home/wdevore/D2/dmd/src/ext/derelict/sdl/endian.d
/home/wdevore/D2/dmd/src/ext/derelict/sdl/error.d
/home/wdevore/D2/dmd/src/ext/derelict/sdl/events.d
/home/wdevore/D2/dmd/src/ext/derelict/sdl/keyboard.d
/home/wdevore/D2/dmd/src/ext/derelict/sdl/keysym.d
/home/wdevore/D2/dmd/src/ext/derelict/sdl/mouse.d
/home/wdevore/D2/dmd/src/ext/derelict/sdl/video.d
/home/wdevore/D2/dmd/src/ext/derelict/sdl/mutex.d
/home/wdevore/D2/dmd/src/ext/derelict/sdl/joystick.d
/home/wdevore/D2/dmd/src/ext/derelict/sdl/syswm.d
/home/wdevore/D2/dmd/src/ext/derelict/sdl/sdlversion.d
/home/wdevore/D2/dmd/src/ext/derelict/sdl/loadso.d
/home/wdevore/D2/dmd/src/ext/derelict/sdl/thread.d
/home/wdevore/D2/dmd/src/ext/derelict/sdl/timer.d

The program actually does very little:

import derelict.opengl.gl;
import derelict.sdl.sdl;
import std.stdio;

void main()
{
    try {
        DerelictGL.load();
        writefln("Successfully loaded the OpenGL shared library.");
    } catch (Exception e) {
        writefln("Could not load the OpenGL shared library.");
    }

        // load the SDL shared library
        try {
                DerelictSDL.load();
                writefln("Successfully loaded the SDL shared library.");
        } catch (Exception e) {
                writefln("Could not load the SDL shared library.");
                writefln(e.msg);
                return -1;
        }
}

You might be wondering why I don't use libraries. Currently, the linker on
linux is having trouble resolving references within libraries. So my work
around was to link directly to the .o files. The problem is that when to many
parameters are passed to dmd, it crashes. I would actually like to get "ld" to
able to resolve references. I realize that the ABI was changed but I compiled
everything from scratch. Clay Smith's suggestion help some, by suggesting I
replace all

struct x;

with 

struct x {}

This fixed alot of unresovled references but I still get the following when
compiling the simple program against the derelict libraries (the output is from
bud is verbose mode, I get a bunch of ...ModuleInfo... things unresolved):

Compiling with ..........
-version=Posix -L-ldl -L-lDerelictUtil -L-lDerelictGL -L-lDerelictSDL -w -op
-I"/home/wdevore/D2/Derelict/DerelictGL/"
-I"/home/wdevore/D2/Derelict/DerelictUtil/"
-I"/home/wdevore/D2/Derelict/DerelictSDL/" -I"/home/wdevore/D2/dmd/src/phobos/"
-I"/home/wdevore/D2/test/" test.d

Running '/home/wdevore/D2/dmd/bin/dmd -c -version=Posix -L-ldl -L-lDerelictUtil
-L-lDerelictGL -L-lDerelictSDL -w -op -I"/home/wdevore/D2/Derelict/DerelictGL/"
-I"/home/wdevore/D2/Derelict/DerelictUtil/"
-I"/home/wdevore/D2/Derelict/DerelictSDL/" -I"/home/wdevore/D2/dmd/src/phobos/"
-I"/home/wdevore/D2/test/" test.d '
Successful
Setting LIB=/home/wdevore/D2/Derelict/lib:/home/wdevore/D2/dmd/lib
Linking with ..........
-ldl -lDerelictUtil -lDerelictGL -lDerelictSDL test.o -o test -lc -lphobos
-lpthread -lm -L/home/wdevore/D2/Derelict/lib -L/home/wdevore/D2/dmd/lib

Running '/usr/bin/gcc -ldl -lDerelictUtil -lDerelictGL -lDerelictSDL test.o -o
test -lc -lphobos -lpthread -lm -L/home/wdevore/D2/Derelict/lib
-L/home/wdevore/D2/dmd/lib'
test.o:(.data+0x8c): undefined reference to
`_D8derelict6opengl2gl12__ModuleInfoZ'
test.o:(.data+0x90): undefined reference to
`_D8derelict3sdl3sdl12__ModuleInfoZ'
test.o: In function `_Dmain':test.d:(.gnu.linkonce.t_Dmain+0xe): undefined
reference to `_D8derelict6opengl2gl10DerelictGL4loadFAaZv'
:test.d:(.gnu.linkonce.t_Dmain+0x4d): undefined reference to
`_D8derelict3sdl3sdl11DerelictSDLS8derelict4util6loader13GenericLoader'
:test.d:(.gnu.linkonce.t_Dmain+0x52): undefined reference to
`_D8derelict4util6loader13GenericLoader4loadMFAaZv'
collect2: ld returned 1 exit status
Failed. Return code: 0100

------------------------------
I am not sure if I should submit the linker issues seperately. I am not sure
what else to do.


--
Dec 27 2006
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=758






Do you mean that the compiler seg faults while compiling, or the linker seg
faults when linking?


--
Dec 29 2006
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=758








 Do you mean that the compiler seg faults while compiling, or the linker seg
 faults when linking?
 


Hi Walter,

It appears as though the compiler is seg faulting because bud(aka build)
generates the "-c" option. linux's ld seems to be able to link fine as long as
all the .o files can be located. However, when dmd seg faults some .o files are
not present and then the linker complains based on the missing .o files.

Bud dosen't seem to recognize that dmd seg faults and blindly calls "ld" to
link. If I manually make sure all the .o files are compiled I can then link
using "ld". But that is for another forum. ;-).

If I had a choice I would rather figure out why dmd (or is it "ar" under linux)
that seems to create library files with missing things in it; most notably the
ModuleInfo things. If I can get that working again I could go back to using
libraries.

Please let me know if I can supply anymore info. I can recreate the issue.

-Will.


--
Dec 31 2006
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=758






I just want it known that Bud uses the system() function to invoke the
compiler. If this is returning zero when the compiler segfaults then there is
not much more I can do.

    lRC = system(std.string.toStringz(pCommand));
    version(Posix) lTrueRC = ((lRC & 0xFF00) >> 8);
    version(Windows) lTrueRC = lRC;

I suppose I could check that all the files being passed to the linker do in
fact exist, but as the linker does that check anyway it would be a bit
redundant.


--
Dec 31 2006
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=758








 I just want it known that Bud uses the system() function to invoke the
 compiler. If this is returning zero when the compiler segfaults then there is
 not much more I can do.
 
     lRC = system(std.string.toStringz(pCommand));
     version(Posix) lTrueRC = ((lRC & 0xFF00) >> 8);
     version(Windows) lTrueRC = lRC;
 
 I suppose I could check that all the files being passed to the linker do in
 fact exist, but as the linker does that check anyway it would be a bit
 redundant.
 


I didn't mean to imply anything was wrong with bud--I use it alot-- Bud is a
great tool btw. I have made a local customization to compile only one file at a
time which gets me past this ticket's issue (for a short while).

I ventured into the depths of phobos to see what the code is doing to handle
SIGSEGV. process.d is simply calling the kernel's system call and returning the
result.


--
Dec 31 2006
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=758


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |clugdbug yahoo.com.au
         Resolution|                            |INVALID





This bug is ancient and has no test case. A huge number of bugs have been fixed
that could have been causing it.
I'm closing this as invalid. If a new test case is found, create a new bug
report.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 04 2009