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]

Help debugging signal sources with gdb


Hi all,

Signals seem to really confuse gdb under cygwin (win7-x64), usually leading to stack traces somewhere in kernelbase.dll or ntdll.dll with no hint of the actual code responsible for the error. In particular, SIGABRT and SIGSEGV would be nice to catch a little closer to the source.

SIGABRT example (workaround: set a breakpoint on the abort() function):
$ cat > sigabrt.c <<EOF
> #include <assert.h>
> int main() { assert(0); }
> EOF

[Ryan@ryan-cms-utsc] ~/experiments
$ gcc -g sigabrt.c

[Ryan@ryan-cms-utsc] ~/experiments
$ gdb --quiet a
Reading symbols from /home/Ryan/experiments/a...done.
(gdb) r
Starting program: /home/Ryan/experiments/a
[New Thread 10060.0x18b4]
warning: cYgFFFFFFFF 61184840
[New Thread 10060.0x2970]
warning: cYgstd 28ccf5 d 3

Program received signal SIGABRT, Aborted.
0x76eaf8c1 in ntdll!RtlUpdateClonedSRWLock () from /cygdrive/c/Windows/system32/ntdll.dll
(gdb) bt
#0 0x76eaf8c1 in ntdll!RtlUpdateClonedSRWLock () from /cygdrive/c/Windows/system32/ntdll.dll
#1 0x76eaf8c1 in ntdll!RtlUpdateClonedSRWLock () from /cygdrive/c/Windows/system32/ntdll.dll
#2 0x76350a91 in WaitForSingleObjectEx () from /cygdrive/c/Windows/syswow64/KERNELBASE.dll
#3 0x00000218 in ?? ()
#4 0x00000000 in ?? ()
(gdb)

SIGSEVG example (no known workaround; I'm pretty sure sigsegv.c does *not* corrupt the stack):
$ cat > sigsegv.c <<EOF
> #include <stdlib.h>
> int main() { return atoi(0); }
> EOF
$ gcc -g sigsegv.c
$ gdb --quiet a
Reading symbols from /home/Ryan/experiments/a...done.
(gdb) r
Starting program: /home/Ryan/experiments/a
[New Thread 11932.0x2c40]
warning: cYgFFFFFFFF 61184840
[New Thread 11932.0x2ca0]
warning: cYgstd 28ccf5 d 3

Program received signal SIGSEGV, Segmentation fault.
0x7634b9bc in RaiseException ()
   from /cygdrive/c/Windows/syswow64/KERNELBASE.dll
(gdb) bt
#0  0x7634b9bc in RaiseException ()
   from /cygdrive/c/Windows/syswow64/KERNELBASE.dll
#1  0x76352ad6 in OutputDebugStringA ()
   from /cygdrive/c/Windows/syswow64/KERNELBASE.dll
#2  0x40010006 in ?? ()
#3  0x00000000 in ?? ()
(gdb)

Running either toy program with cygwin1.dbg available adds some details (like arguments and line numbers for some functions) but still doesn't give a stack trace that includes main().


About half the time the seg faulting example puts _strtol_r() (strtol.c:152) at the top of the bogus stack trace instead of RaiseException (no sign of its ancestors: strtol, atoi and main); independently, there's a 50/50 chance of a STATUS_ACCESS_VIOLATION and a stack dump, but it's patchy. I'm pretty sure the seg fault isn't due to a corrupted stack, because all the code does is try to access *s when s==0:
151             do {
152                     c = *s++;
153             } while (isspace(c));

I know I'm probably the only cygwin user that writes code that seg faults, but does anybody have a suggestion on how to work around this?


The relevant package versions are:
binutils                    2.21.53-1
cygwin                      1.7.9-1
gcc4                        4.5.0-1
gcc4-core                   4.5.0-1
gcc4-g++                    4.5.0-1
gdb                         7.3.50-1

Thanks!
Ryan


-- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple


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