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: Program exited with code 0303000

> -----Original Message-----
> From: cygwin-owner On Behalf Of Dan Osborne
> Sent: 28 September 2004 13:22

> I was trying to step through the code in gdb and pin this 
> down so setting
> breaks on abort and exit sounds useful. However, both b abort 
> and b exit
> give me ...
> (gdb) b abort
> Breakpoint 1 at 0x401552: file otlv4.h, line 3608.
> (gdb) b exit
> Note: breakpoint 1 also set at pc 0x401552.
> Breakpoint 2 at 0x401552: file otlv4.h, line 3608.
> But line 3608 of otlv4.h looks like nothing to do with abort or exit
> add_var(i,var,in_out,apl_tab_size);

  Um.  Bizarre.  You did build with -g and -O0, didn't you?  Is this an actual
function call here, or does add_var turn out to be some kind of macro or something
that otherwise gets inlined?

> However, further digging reveals that my program gets to the 
> throw command here ...
> catch ( RProgReturnException e )
> {
>    throw;
> }
> and if I step on throw the debugger thinks I'm at ... gues 
> which line?! yes, line 3608 of otlv4.h ...
> (gdb) s
> 0x1003b115 in __cxa_rethrow () at otlv4.h:3608
> 3608              add_var(i,var,in_out,apl_tab_size);

  You didn't say what function that catch instruction is actually in: is it in the
function that calls add_var, or is it in add_var and add_var has been inlined at
this point?  In any case, it certainly seems to be in the right place, considering
you are indeed re-throwing an exception.
> and if I step again I get ...
> Program exited with code 0303000.

  Hmm.  Have you properly used 'throws XXX' declarations on all the function
prototypes that need them?

> So I'm wondering firstly why gdb seems to have a mismatch 
> between address
> and source line number and why that throw didn't get caught 
> in my catch in
> main.

  You haven't shown me your main catch clause, but I'll assume that it covers all
exception types (or at any rate, that it includes RProgReturnException).  As I
suggest above, giving bad information to the compiler (through missing or bogus
throws decls) can cause it to generate bad unwind info: and we can pretty much
presume that the unwind info has to be bad in some way and that's why it's missing
your outer catch when it unwinds.

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]