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


On Mon, Oct 10, 2005 at 11:18:06AM -0400, Christopher Faylor wrote:
>On Mon, Oct 10, 2005 at 06:13:15AM -0600, Eric Blake wrote:
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>According to Peter J. Stieber on 10/9/2005 7:59 PM:
>>> It's attached. I added the -t command to the g++ command so the loader
>>> would list the files it was processing when it breaks. The name of the
>>> object file in the last line should be SimpleInterpolationTable.o, but
>>> it gets truncated.
>>
>>> (/home/pete/Build/lib/libUtilityg.a)SimpleInterpolmake: *** [slamem.exe]
>>> 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.
>
>This seems like a real shot in the dark to me.  What would not be
>terminating a truncated command line?  Cygwin?  That's not likely.
>
>AFAIK, only very recent CVS versions of binutils take '@' command line
>arguments, although cygwin will honor them itself for processes which
>are not started by a cygwin process.  I don't see any indication that
>this is the problem here.
>
>If this is a command-line length problem then something like:
>
>  mount -X -b c:/cygwin/bin /bin
>  mount -X -b c:/cygwin/bin /usr/bin
>
>would probably fix it.
>
>See: http://cygwin.com/faq/faq-nochunks.html#faq.programming.make-execvp

Btw, if the above doesn't fix this and you can't provide any more
details then it seems like your best bet would be to build a debugging
version of binutils and see where the core dump is coming from.

If you include "error_start:c:/cygwin/bin/gdb.exe" in your CYGWIN
environment variable, it will start gdb automatically when a SEGV is
encountered.

cgf

--
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]