Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
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
From:	"Dave Korn" <dk AT artimi DOT com>
To:	<cygwin AT cygwin DOT com>
Subject:	RE: gcc exception handling
Date:	Tue, 12 Oct 2004 18:11:45 +0100
MIME-Version:	1.0
In-Reply-To:	<20041012165842.37385.qmail@web60802.mail.yahoo.com>
Message-ID:	<NUTMEGuLeHTgzW2hSsK000003fb@NUTMEG.CAM.ARTIMI.COM>
X-OriginalArrivalTime:	12 Oct 2004 17:11:45.0907 (UTC) FILETIME=[8D788430:01C4B07E]

> -----Original Message-----
> From: cygwin-owner On Behalf Of Peter Xiaochuan Huang
> Sent: 12 October 2004 17:59

> I don't know if this a known issue. But I encounter
> this problem when using gcc 3.3.3 on cygwin. The code
> similar to below core dumps me.
> 
>    try {
>       obj->dothis();
>    }
>     catch ( myexception& e)
>     {
>         return true;
>      }
> 
> It core dumps on the return statement in gdb. But when
> I make a simplified test including only above code,
> the core dump doesn't happen any more. My program that
> gets core dumped links pthread and uses mutex.
> Actually the return statement should invoke stack
> unwinding that will do mutex locking and unlocking.
> Though I don't know if that is related or not.

  Are you using the correct command line options to compile with exceptions?

  Are you doing the final link using g++ rather than gcc?

  Do all functions have the correct throw specifiers on their prototypes?
 
> Anybody else has similar problem ? 

  Maybe the same problem: we never resolved it yet:
http://www.cygwin.com/ml/cygwin/2004-09/msg01380.html 

  Are there any shared libraries involved?

>Any suggestion?

1)  Keep trying to come up with a simple testcase?
2)  Switch gdb into assembly code view and debug the problem by seeing what
actual values are in registers, stack and memory and what actual machine
code instructions are getting executed to cause the problem?

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


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

- Raw text -