Segmentation fault when exception is thrown or assertion fails [g++/gcc]

[Roman Werpachowski]

I get the following output:

      4 [sig] a 1408 _cygtls::handle_exceptions: Error while dumping
state (probably corrupted stack)
Segmentation fault (core dumped)

When running the following test programs:

#include <assert.h>

int main(void)
{
    assert( 1 == 0 );
    return 0;
}

or

#include <cassert>
#include <stdexcept>

int main()
{
    throw new std::runtime_error("Just because"); // the same with
assert(false);
}

I am using gcc-3.4.4.

I understand that Cygwin defaults to dumping the stack trace, but why
the message about segmentation fault? It confuses the hell out of me.

Regards,
Roman Werpachowski

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

[Christopher Faylor-8]

On Sun, Jul 05, 2009 at 04:18:44AM +0100, Roman Werpachowski wrote:

>I get the following output:
>
>      4 [sig] a 1408 _cygtls::handle_exceptions: Error while dumping
>state (probably corrupted stack)
>Segmentation fault (core dumped)
>
>When running the following test programs:
>
>#include <assert.h>
>
>int main(void)
>{
>    assert( 1 == 0 );
>    return 0;
>}
>
>or
>
>#include <cassert>
>#include <stdexcept>
>
>int main()
>{
>    throw new std::runtime_error("Just because"); // the same with
>assert(false);
>}
>
>I am using gcc-3.4.4.
>
>I understand that Cygwin defaults to dumping the stack trace, but why
>the message about segmentation fault? It confuses the hell out of me.

Please provide these details
                       |||||||||||||||||||||||||||||||
                       VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV

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

[Roman Werpachowski]

Some more details about my problem
(http://cygwin.com/ml/cygwin/2009-07/msg00150.html)

$ gcc -v
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /managed/gcc-build/final-v3-bootstrap/gcc-3.4.4-999/configure -
-verbose --program-suffix=-3 --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/s
hare/info --enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --wit
hout-included-gettext --enable-version-specific-runtime-libs --without-x --enabl
e-libgcj --disable-java-awt --with-system-zlib --enable-interpreter --disable-li
bgcj-debug --enable-threads=posix --enable-java-gc=boehm --disable-win32-registr
y --enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debu
g
Thread model: posix
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)

Stack trace for the C program:

Stack trace:^M
Frame     Function  Args^M
0022C928  7C802542  (000007CC, 0000EA60, 000000A4, 0022C970)^M
0022CA48  61097F54  (00000000, 7C802600, 7C802542, 000000A4)^M
0022CB38  61095AEB  (00000000, 003B0023, 00230000, 0022CE68)^M
0022CB98  61095FCB  (0022CBB0, 00000000, 00000094, 61020C1B)^M
0022CC58  61096182  (00000CAC, 00000006, 0022CC88, 61096383)^M
0022CC68  610961AC  (00000006, 0022CE88, 000062A6, 6109A7DF)^M
0022CC88  61096383  (6110D008, 00402000, 00402007, 00000005)^M
0022CCB8  61001087  (00402007, 00000005, 00402000, 00401075)^M
0022CCE8  610935A8  (00000001, 6116B6B0, 006B0090, 0022CC70)^M
0022CD98  610060D8  (00000000, 0022CDD0, 61005450, 0022CDD0)^M
61005450  61004416  (0000009C, A02404C7, E8611021, FFFFFF48)^M
Exception: STATUS_ACCESS_VIOLATION at eip=61016583^M
eax=EC815356 ebx=61108148 ecx=00000000 edx=57E58959 esi=0000000B edi=00000001^M
ebp=006AC8B8 esp=006AC8B0 program=d:\Moje dokumenty\Programs\test_c.exe, pid 324
4, thread sig^M
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023^M
Stack trace:^M
Frame     Function  Args^M
006AC8B8  61016583  (61108148, 6111C19B, FFFFFF48, 00000000)^M
006AC8D8  610166EC  (00000001, 00000000, 00000000, 006AC960)^M
006AC918  61017FD5  (000007B8, 006AC960, 00000000, 00000000)^M
006ACC58  61018638  (00000744, 006ACC90, 000000A4, 006ACC8C)^M
006ACD58  61099F57  (61106F00, 00000000, 00000000, 00000000)^M
006ACD88  61002F32  (006ACE64, 61018970, 00001074, 00000000)^M
61003650  61003769  (04A16430, 89000000, FFDA90B0, 24468BFF)^M
      4 [sig] test_c 3244 _cygtls::handle_exceptions: Error while dumping state
(probably corrupted stack)

Stack trace for the C++ program:

Stack trace:^M
Frame     Function  Args^M
0022C868  7C802542  (00000738, 0000EA60, 000000A4, 0022C8B0)^M
0022C988  61097F54  (00000000, 7C802600, 7C802542, 000000A4)^M
0022CA78  61095AEB  (00000000, 003B0023, 00230000, 0022CE68)^M
0022CAD8  61095FCB  (0022CAF0, 00000000, 00000094, 61020C1B)^M
0022CB98  61096182  (00000F38, 00000006, 0022CBC8, 61096383)^M
0022CBA8  610961AC  (00000006, 0022CE88, 0022CC18, 004049D3)^M
0022CBC8  61096383  (0022CBF8, 00407860, 0022CC7C, 00000001)^M
0022CC18  004049E7  (0022CAA0, 00000000, 0022CCE8, 004011C6)^M
0022CC28  00403216  (006E0278, 00410370, 00403650, 00401081)^M
0022CCE8  004011C6  (00000001, 6116B6B0, 006E0090, 0022CC70)^M
0022CD98  610060D8  (00000000, 0022CDD0, 61005450, 0022CDD0)^M
61005450  61004416  (0000009C, A02404C7, E8611021, FFFFFF48)^M
Exception: STATUS_ACCESS_VIOLATION at eip=61016583^M
eax=EC815356 ebx=61108148 ecx=00000000 edx=57E58959 esi=0000000C edi=00000001^M
ebp=006DC8B8 esp=006DC8B0 program=d:\Moje dokumenty\Programs\test.exe, pid 3896,
 thread sig^M
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023^M
Stack trace:^M
Frame     Function  Args^M
006DC8B8  61016583  (61108148, 6111C19B, FFFFFF48, 00000000)^M
006DC8D8  610166EC  (00000001, 00000000, 00000000, 006DC960)^M
006DC918  61017FD5  (000007B8, 006DC960, 00000000, 00000000)^M
006DCC58  61018638  (00000744, 006DCC90, 000000A4, 006DCC8C)^M
006DCD58  61099F57  (61106F00, 00000000, 00000000, 00000000)^M
006DCD88  61002F32  (006DCE64, 61018970, 00001074, 00000000)^M
61003650  61003769  (04A16430, 89000000, FFDA90B0, 24468BFF)^M
     10 [sig] test 3896 _cygtls::handle_exceptions: Error while dumping state (p
robably corrupted stack)

Apologies for not responding correctly to Chris Faylor, but my mailing
list skills have gone rusty. I will respond to next messages
correctly.

Regards,
Roman Werpachowski

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

[Dave Korn-6]

Roman Werpachowski wrote:
> Some more details about my problem
> (http://cygwin.com/ml/cygwin/2009-07/msg00150.html)
>
> $ gcc -v

  Actually even more useful would be to know what Cygwin DLL version you're
running.  The problems page that CGF directed you to contains in particular
the advice to run "cygcheck -s -v -r > cygcheck.out" and then send the
cygcheck.out file ** as an attachment, not inline, please ** to the list with
your post.

  From your earlier post:

> I understand that Cygwin defaults to dumping the stack trace, but why
> the message about segmentation fault? It confuses the hell out of me.

  Well, what happened was that there's a bug somewhere, and while cygwin was
in the process of dumping the stack trace for the abort caused by your
assertion firing, the DLL itself had a segfault, and had to give up.  It said
"probably corrupted stack", because that's the most common reason why you
might end up following a stray pointer and causing a segfault when you were
trying to unwind the stack, but in this case it's unlikely anything would have
corrupted the stack, so either there's a real bug or perhaps just some kind of
frame-pointer optimisation that confuses the unwind routine.

  I tried your example with both gcc-4 and gcc-3 on current 1.7 and it worked
just fine:

> $ cat ass.c
> #include <assert.h>
>
> int main(void)
> {
>     assert( 1 == 0 );
>     return 0;
> }
>
> $ gcc -g -O0 ass.c -o ass
>
> $ ./ass.exe
> assertion "1 == 0" failed: file "ass.c", line 5, function: main
> Aborted (core dumped)
>
> $ ls
> ass.c  ass.exe  ass.exe.stackdump
>
> $ cat ass.exe.stackdump
> Stack trace:
> Frame     Function  Args
> 0022CAF8  7C4F1B1B  (00000000, FFFFFFFF, 0022CC28, 00000000)
> 0022CBD8  610B5527  (00000000, 00000000, 00000000, 00000000)
> 0022CC28  610B593B  (00000634, 0022CC50, 77F891D2, 000003D0)
> 0022CCE8  610B5A61  (00000634, 00000006, 0022CD18, 610B5B05)
> 0022CCF8  610B5A9C  (00000006, 0022CE88, 6115444C, 00000101)
> 0022CD18  610B5B05  (61158054, 00402085, 0040208C, 00000005)
> 0022CD48  6100109B  (0040208C, 00000005, 00402080, 00402085)
> 0022CD68  610B2CB8  (6127EE7E, 00000000, 0022CDA8, 61006E4A)
> 0022CDA8  61006E4A  (00000000, 0022CDE0, 61006720, 7FFDF000)
> End of stack trace

  I also tried at -O2, same results.

    cheers,
      DaveK


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

[Roman Werpachowski]

On Sun, Jul 5, 2009 at 1:50 PM, Dave
Korn<dave.korn.cygwin@...> wrote:
>  Actually even more useful would be to know what Cygwin DLL version you're
> running.  The problems page that CGF directed you to contains in particular
> the advice to run "cygcheck -s -v -r > cygcheck.out" and then send the
> cygcheck.out file ** as an attachment, not inline, please ** to the list with
> your post.

Done.

>  Well, what happened was that there's a bug somewhere, and while cygwin was
> in the process of dumping the stack trace for the abort caused by your
> assertion firing, the DLL itself had a segfault, and had to give up.  It said
> "probably corrupted stack", because that's the most common reason why you
> might end up following a stray pointer and causing a segfault when you were
> trying to unwind the stack, but in this case it's unlikely anything would have
> corrupted the stack, so either there's a real bug or perhaps just some kind of
> frame-pointer optimisation that confuses the unwind routine.

I was building my test programs without any optimizations, but with -g
option set.

Regards,
Roman Werpachowski


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

[Dave Korn-6]

Roman Werpachowski wrote:
> On Sun, Jul 5, 2009 at 1:50 PM, Dave
> Korn<dave.korn.cygwin@AAAARRRRRGGGGHHHHHH!!!ooglemail.com> wrote:

  Please don't quote the "From:" address in your email.  Getting someone
spammed is no way to thank them for helping you!  (See
http://cygwin.com/acronyms/#PCYMTNQREAIYR for a full explanation.)

>>  Actually even more useful would be to know what Cygwin DLL version you're
>> running.  The problems page that CGF directed you to contains in particular
>> the advice to run "cygcheck -s -v -r > cygcheck.out" and then send the
>> cygcheck.out file ** as an attachment, not inline, please ** to the list with
>> your post.
>
> Done.

  Right, well that shows you're using 1.5.25, which is known to have bugs in
this area, and is at end-of-life and won't be fixed.  It's a minor
inconvenience, sorry, but it only affects things that happen after your
program crashes anyway, so it was never a big enough priority for anyone to
fix when 1.5 series was still live.

  Tried 1.7 yet?  :-)  It's pretty good!

    cheers,
      DaveK


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

[Roman Werpachowski]

On Sun, Jul 5, 2009 at 3:28 PM, Dave Korn<XXX> wrote:
> Roman Werpachowski wrote:
>> On Sun, Jul 5, 2009 at 1:50 PM, Dave
>
>  Please don't quote the "From:" address in your email.

Extremely sorry, won't happen again. BTW, couldn't the mailing
software automatically remove these addresses?


>  Tried 1.7 yet?  :-)  It's pretty good!

Thanks, I will do it.

Regards,

Roman Werpachowski

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

[Roman Werpachowski]

On Sun, Jul 5, 2009 at 3:28 PM, Dave Korn<XXX> wrote:
>  Right, well that shows you're using 1.5.25, which is known to have bugs in
> this area, and is at end-of-life and won't be fixed.  It's a minor
> inconvenience, sorry, but it only affects things that happen after your
> program crashes anyway, so it was never a big enough priority for anyone to
> fix when 1.5 series was still live.
>
>  Tried 1.7 yet?  :-)  It's pretty good!

Tried, works as advertised. Thank you.

Regards,
Roman Werpachowski

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

[Roman Werpachowski]

On Sun, Jul 5, 2009 at 1:50 PM, Dave Korn<XXXX> wrote:
>  Well, what happened was that there's a bug somewhere, and while cygwin was
> in the process of dumping the stack trace for the abort caused by your
> assertion firing,

One more question: how can I use this stack trace to debug genuine
errors? "gdb -c" cannot load it.

Regards,
Roman Werpachowski

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

[Christopher Faylor-8]

On Sun, Jul 05, 2009 at 05:21:50PM +0100, Roman Werpachowski wrote:
>On Sun, Jul 5, 2009 at 1:50 PM, Dave Korn<XXXX> wrote:
>> ?Well, what happened was that there's a bug somewhere, and while cygwin was
>> in the process of dumping the stack trace for the abort caused by your
>> assertion firing,
>
>One more question: how can I use this stack trace to debug genuine
>errors? "gdb -c" cannot load it.

The stack dump is for human consumption.  gdb doesn't know anything
about it.

You can look up the addresses in gdb by doing something like:

  (gdb) l *0xf00f00fa

Or you can use addr2line.

If you want a real core dump see:

http://www.cygwin.com/cygwin-ug-net/using-utils.html#dumper

cgf

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

[Dave Korn-6]

Roman Werpachowski wrote:
> On Sun, Jul 5, 2009 at 1:50 PM, Dave Korn<XXXX> wrote:
>>  Well, what happened was that there's a bug somewhere, and while cygwin was
>> in the process of dumping the stack trace for the abort caused by your
>> assertion firing,
>
> One more question: how can I use this stack trace to debug genuine
> errors? "gdb -c" cannot load it.

  It's not a full core dump, it's just a stack backtrace in human-readable
format.  If you copy and paste the addresses in the second column (Function)
into "addr2line --exe <path-to-your-executable>" (and assuming you compiled
with debug info), it'll turn them into a list of addresses.

  (Note that in the examples you gave, all the addresses were in the cygwin
DLL, because the compiler had optimised the implied abort() call in the
assert() in your main() function into a tail-call; effectively your code had
already returned from main.)

    cheers,
      DaveK

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

[Roman Werpachowski]

On Sun, Jul 5, 2009 at 6:58 PM, Dave Korn<XXX> wrote:
>  It's not a full core dump, it's just a stack backtrace in human-readable
> format.  If you copy and paste the addresses in the second column (Function)
> into "addr2line --exe <path-to-your-executable>" (and assuming you compiled
> with debug info), it'll turn them into a list of addresses.
>
>  (Note that in the examples you gave, all the addresses were in the cygwin
> DLL, because the compiler had optimised the implied abort() call in the
> assert() in your main() function into a tail-call; effectively your code had
> already returned from main.)

Thanks to you and Chris.

Regards,
Roman Werpachowski

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