Re: [Cygwin64] dash segfault

[Peter Rosin <peda at lysator dot liu dot se>]

On 2013-03-11 17:43, Corinna Vinschen wrote:
> On Mar 11 17:16, Peter Rosin wrote:
>> 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
> 
> Any stackdump file?

I Don't think so, I had already removed that build dir, but in a
fresh build with (at least) three "Segmentation fault" messages,
"find . -name '*.stackdump'" came up empty.

>> 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?
> 
> Just run this DLL for the time being.

Will do.

Cheers,
Peter