This is the mail archive of the cygwin-developers 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: [Cygwin64] dash segfault


On 2013-03-11 16:39, Corinna Vinschen wrote:
> On Mar 11 15:35, Peter Rosin wrote:
>> On 2013-03-11 13:32, Corinna Vinschen wrote:
>>> I've just uploaded a new 64 bit Cygwin DLL package 1.7.18-3.  Can you
>>> please restart testing with this version?  I'm trying for about an
>>> hour to reproduce the problem now, but so far I didn't succeeed, which
>>> is a good sign, hopefully.
>>
>> Good new first, it seems to be less frequent! But there's still
>> something bad going on, so sorry, no cigar...
> 
> Too bad.  Unfortunately the backtrace is not helpful.
> 
>> Second, there's the non-crash exit (where dash sometimes exits w/o
>> triggering error_start, this still happens with -3):
>> [...]
>> Third (which I haven't reported previously, but I have seen it with -2 as
>> well), sometimes gdb gets triggered by error_start, but it fails to attach
>> to the process. When this happens I see this in the gdb window (after the
>> boilerplate):
>>
>> Reading symbols from /usr/bin/dash.exe...done.
>> Can't attach to process.
>> /cygdrive/c/Cygwin/home/peda/ggi/cyg64/ggi/default-shared/47784: No such file or directory.
>> (gdb) 
> 
> Hmm, maybe the process doesn't exist anymore for some reason.
> 
>> Lastly, I have a tiny unrelated wishlist request of very low priority.
>> Could the w32api headers be updated to the latest from the mingw64 repo
>> the next time there's a gcc update? I had a small patch upstreamed that
>> will enable me to drop a local workaround. Thanks!
> 
> I'll see to it for the next rebuild, but right now Mingw HEAD doesn't
> build for me.
> 
> Can you please test something for me?  Can you please try the files
> 
> ftp://ftp.cygwin.com/pub/cygwin/64bit/cygwin1.dbg.bz2
> ftp://ftp.cygwin.com/pub/cygwin/64bit/cygwin1.dll.bz2
> 
> Bunzip them and install into /bin and try again.  I would like to test
> an assumption.

I got one new symptom, at one point there was this "Hangup" in the
middle of the output:

checking if we should build filter-save... yes
checking if we should build filter-tcp... yes
checking if we should build filter-tile... yes
Hangup
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating gii/Makefile

Also, later I noticed this in the output:

config.status: creating config.h
config.status: executing depfiles commands
Segmentation fault
config.status: executing libtool commands
exit status: 0

And then last, but not least, in another configure run:

checking for dlfcn.h... yes
checking for as... as
checking for dlltool... (cached) dlltool
checking for objdump... (cached) objdump
checking for objdir... .libs
exit status: 0

(exit status is written by my build script)

But no crashes into gdb yet, should I keep going for one of
those or did you get sufficient answers?

Cheers,
Peter


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