This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 1.5.18: ld command generates stackdump


PS = Peter J. Stieber on 10/9/2005 7:59 PM:
PS>>>> It's attached. I added the -t command to the g++ command so
PS>>>> the loader would list the files it was processing when it breaks.
PS>>>> The name of the object file in the last line should be
PS>>>> SimpleInterpolationTable.o, but it gets truncated.
PS>>>> (/home/pete/Build/lib/libUtilityg.a)SimpleInterpolmake: *** [slamem.exe]
PS>>>> Error 1


You may be hitting command line length limitations. I'm wondering if the
core dump happens because the truncated argument was not NUL-terminated.
Have you considered bundling arguments into a temporary file, then passing
@filename as the lone argument to ld, to bypass the command-line length
limitations? You may also want to try mounting ld's directory as cygexec,
or trying a recent snapshot, both of which use cygwin magic to increase
the command-line length of cygwin applications.

CF = Christopher Faylor
CF>> This seems like a real shot in the dark to me.
CF>> What would not be terminating a truncated
CF>> command line? Cygwin? That's not likely.
CF>>
CF>> AFAIK, only very recent CVS versions of
CF>> binutils take '@' command line arguments,
CF>> although cygwin will honor them itself for
CF>> processes which are not started by a cygwin
CF>> process. I don't see any indication that
CF>> this is the problem here.
CF>>
CF>> If this is a command-line length problem then something like:
CF>>
CF>> mount -X -b c:/cygwin/bin /bin
CF>> mount -X -b c:/cygwin/bin /usr/bin
CF>>
CF>>would probably fix it.
CF>>
CF>> See: http://cygwin.com/faq/faq-nochunks.html#faq.programming.make-execvp


I tried this, but I am still seeing the problem. Calling the mount comment results in the following:

CF> Btw, if the above doesn't fix this and you can't provide
CF> any more details then it seems like your best bet would
CF> be to build a debugging version of binutils and see where
CF> the core dump is coming from.
CF>
CF> If you include "error_start:c:/cygwin/bin/gdb.exe" in
CF> your CYGWIN environment variable, it will start gdb
CF> automatically when a SEGV is encountered.

Sorry in advance for the stupid questions, but...

I downloaded the binutils source package, and extracted the source. When I ran

./configure --help

I didn't see a --enable-debug option or anything I though was equivalent. Am I missing something?

Do I also need to build a debug version of the cygwin DLL?

Pete



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]