X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-1.0 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL
X-Spam-Check-By:	sourceware.org
Message-ID:	<4E4C6DF9.7060109@cs.utoronto.ca>
Date:	Wed, 17 Aug 2011 21:42:17 -0400
From:	Ryan Johnson <ryan DOT johnson AT cs DOT utoronto DOT ca>
User-Agent:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version:	1.0
To:	"cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject:	Help debugging signal sources with gdb
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

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 AT ryan-cms-utsc] ~/experiments
> $ gcc -g sigabrt.c
>
> [Ryan AT 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

- Raw text -