This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: gcc exception handling

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

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

Can't think of a witty .sigline today....

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]