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:	Thu, 14 Oct 2004 13:33:54 +0100
MIME-Version:	1.0
In-Reply-To:	<20041013175031.37162.qmail@web60802.mail.yahoo.com>
Message-ID:	<NUTMEGFjjBsVVP9AtFo00000489@NUTMEG.CAM.ARTIMI.COM>
X-OriginalArrivalTime:	14 Oct 2004 12:33:55.0548 (UTC) FILETIME=[11FD19C0:01C4B1EA]

> -----Original Message-----
> From: cygwin-owner On Behalf Of Peter Xiaochuan Huang
> Sent: 13 October 2004 18:51

> >   Are you using the correct command line options to
> > compile with exceptions?
> 
>     I tried -mthreads that didn't fix it. What is the
> right compile flag?

  I believe -fexceptions is vital if you're using exceptions.  That should
be automatically the case for any C++ files you're compiling but if there
are plain old C files in your application as well they also need
-fexceptions when compiled.

> >   Do all functions have the correct throw specifiers
> > on their prototypes?
> 
>     None of my functions has any throw specifier,
> which means throw possibly anything. Is that good
> enough ?

  I believe it should be.  C++ exceptions are not my strong point, however.

> > 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?
> 
>     I may have to try this if the compile flag you
> give to me doesn't fix the problem

  I fear you may have to.  Looking again at your original description of the
problem:

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

it seems likely to me that if you can't reduce it to a fairly simple
testcase, it could well indicate that there is some bug (perhaps a
threading-related race condition, or something else that might cause memory
corruption) in your code that is corrupting state and causing an error as
the stack is unwound.

    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 -