Re: [Cygwin64] dash segfault

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

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

I've seen errors of three classes with -3. First, there's the
well-known limited-stack-bt crash (but this one looks a little
bit different for thread 2):

Thread 4 (Thread 9636.0xb830):
#0  0x0000000076eb0531 in ntdll!DbgBreakPoint ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#1  0x0000000076f57ef8 in ntdll!DbgUiRemoteBreakin ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#2  0x0000000000000000 in ?? ()

Thread 3 (Thread 9636.0xb5e4):
#0  0x0000000076eb135a in ntdll!ZwWaitForSingleObject ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#1  0x000007fefd4b10dc in WaitForSingleObjectEx ()
   from /cygdrive/c/Windows/system32/KERNELBASE.dll
#2  0x0000000000000000 in ?? ()

Thread 2 (Thread 9636.0xb7b0):
#0  0x0000000076eb137a in ntdll!ZwReadFile ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#1  0x000007fefd4b1a7a in ReadFile ()
   from /cygdrive/c/Windows/system32/KERNELBASE.dll
#2  0x000000000022ce00 in ?? ()
#3  0x00000001802da8f8 in fhandler_disk_file::isdevice ()
   from /usr/bin/cygwin1.dll
#4  0x000000018006e390 in try_to_debug ()
---Type <return> to continue, or q <return> to quit---
    at /usr/src/debug/cygwin-1.7.18-3/winsup/cygwin/exceptions.cc:500
#5  0x000000000062aa40 in ?? ()
#6  0x000000000062aaf0 in ?? ()
#7  0x00000000000000b0 in ?? ()
#8  0x0000000000000000 in ?? ()

Thread 1 (Thread 9636.0x85ac):
#0  0x0000000076eb165a in ntdll!ZwDelayExecution ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#1  0x000007fefd4b1203 in SleepEx ()
   from /cygdrive/c/Windows/system32/KERNELBASE.dll
#2  0x00000000002285f8 in ?? ()
#3  0x0000000000000001 in ?? ()
#4  0x0000000000000000 in ?? ()


Second, there's the non-crash exit (where dash sometimes exits w/o
triggering error_start, this still happens with -3):

Basically, this time config.status didn't complete, and the configure
output ended with:

config.status: creating m4/Makefile
config.status: creating libgii.conf

but it is expected that it carries on with:

config.status: creating dist/Makefile
config.status: creating dist/rpm/Makefile
config.status: creating dist/rpm/libgii.spec
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands


That premature unexplained exit later killed make with:

...
Making all in input
make[2]: Entering directory `/cygdrive/c/Cygwin/home/peda/ggi/cyg64/gii/input'
Making all in directx
make[3]: Entering directory `/cygdrive/c/Cygwin/home/peda/ggi/cyg64/gii/input/directx'
Makefile:314: .deps/di.Plo: No such file or directory
Makefile:315: .deps/dxguid.Plo: No such file or directory
Makefile:316: .deps/input.Plo: No such file or directory
...

due to the deps not being there.

This bug is really troublesome, it does not give me a cozy feeling when
scripts only get half-done w/o any notice...


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) 


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!

Cheers,
Peter