This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
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