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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=758





------- Comment #1 from bugzilla@digitalmars.com  2006-12-29 14:48 -------
Do you mean that the compiler seg faults while compiling, or the linker seg faults when linking?


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=758





------- Comment #2 from quartz13163@distanthumans.info  2006-12-31 17:06 -------
(In reply to comment #1)
> 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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=758





------- Comment #3 from ddparnell@bigpond.com  2006-12-31 17:32 -------
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.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=758





------- Comment #4 from quartz13163@distanthumans.info  2006-12-31 19:47 -------
(In reply to comment #3)
> 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.


-- 

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




--- Comment #5 from Don <clugdbug@yahoo.com.au>  2009-09-04 06:27:52 PDT ---
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: -------