X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=4.2 required=5.0 tests=BAYES_00,BOTNET,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC,TW_YG
X-Spam-Check-By:	sourceware.org
Date:	Mon, 21 Feb 2011 20:23:43 -0500
From:	Stan <smoore AT exis DOT net>
To:	cygwin AT cygwin DOT com
Subject:	[reply-to-list-only-lh AT cygwin DOT com: Re: assert broken?]
Message-ID:	<20110222012343.GA7841@home.invalid>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
MIME-Version:	1.0
User-Agent:	Mutt/1.5.17 (2007-11-01)
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

Larry Hall
>On 2/17/2011 1:49 PM, Stan wrote:
>>
>> I've run cygcheck and tried this on two systems with the same
>> results; at this point I'm assuming the problem is not local so I'm
>> not including the typically requested data. I will be glad to follow
>> up if my assumption turns out to be incorrect.
>>
>> The issue is triggering an assert dumps core. Trivial test case:
>>
>> #include<assert.h>
>>
>> int main()
>> {
>>     assert(1==0);
>>     return 1;
>> }
>>
>> causes a core dump. I originally noticed this is a gdb session and the
>> triggered assert leaves a bt showing windows info so it looks like the
>> stack unwinding is having a bad day.
>
>When an assertion fails, it calls abort().
>
><http://pubs.opengroup.org/onlinepubs/009695399/functions/assert.html>
>
>Are you saying it's not doing this?

No, it calls abort; I get that. I wasn't clear the issue isn't a
normal core dump with useable data, the core always shows a few
unhelpful stack frames in ntdll. Same in gdb, the stackdump is not
showing any user frames at all. Even setting a break in gdb on assert
leaves you with a stack dump as follows:

#0  0x776ff861 in ntdll!RtlUpdateClonedSRWLock () 
    from C:\windows\SysWOW64\ntdll.dll
(gdb) bt
#0  0x776ff861 in ntdll!RtlUpdateClonedSRWLock () 
    from C:\windows\SysWOW64\ntdll.dll
#1  0x776ff861 in ntdll!RtlUpdateClonedSRWLock () 
    from C:\windows\SysWOW64\ntdll.dll
#2  0x77210816 in WaitForSingleObjectEx () 
    from C:\windows\syswow64\KERNELBASE.dll
#3  0x00000140 in ?? ()
#4  0x00000000 in ?? ()

I mangled and wrapped the above manually. In my experience i normally
see helpful information including the function calls leading to the
assert. Seems something is happening during the stack unwinding and
the resulting core is sub optimal. I'm not trying or expecting to
trace through assert, I'd just like to see a trace leading up the
event.


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