RE: Program exited with code 0303000

["Dan Osborne" <dan dot osborne at ramesys dot com>]

OK, my voyage of discovery continues. I've added exception specifications to
the appropriate functions (declarations and definitions - took a while to
work out I needed it on both) but no change in behaviour.

I've also remembered why I started to look at dumper.exe - If I don't run
the prog in gdb then instead of "Program exited with code 0303000" I get ...

Aborted (core dumped)

Presumably because of the uncaught exception, despite a catch (...) in my
main.

My main is mostly this ...

   try
   {
      char* s = strclone( cfg.getString( "FIRST_SCREEN" ) );
      RProg::Mode m = (RProg::Mode)cfg.getInt( "FIRST_MODE" );
      RProg::runScreen( s, m );
      delete[] s;
   }
   catch( RException& e )
   {
      RProg::displayMessage(e.what());
   }
   catch (...)
   {
      RProg::displayMessage("An unknown exception occurred");
   }

Most of the application is happening in the RProg class which is in a shared
object and loads other shared objects using the same runScreen function
above (it uses dlopen). These usually exit by throwing the same exception
(strange approach I know but the application is a translation of one written
in PowerHouse 4GL where the return verb is used to exit screens and I
couldn't think of a better way to implement this in C++).

The problem doesn't occur if the loaded shared objects don't do any database
activity and the C++ library that uses the odbc32.dll has all its code in
the otlv4.h header file with many inline functions. Might it help further
investigation if I split the header file into a .h and a .cc with no inline
functions?

Also, earlier there was some mention of linking statically against the
odbc32.dll - is that worth trying? As you can probably tell I'm up against
the limit of my knowledge in this area and am not sure how to do it.

Currently I do this to create the shared object ...

g++ -shared -Wl,--out-implib=libcxxdll.dll.a \
-o librbase.so rdata.o rchar.o rdate.o rdatetime.o rfloat.o rinteger.o
rfromany.
o rany.o roperator.o rnumber.o rexception.o rprog.o csql.o rfile.o rcrc32.o
robj
ect.o rlist.o rlogger.o rconfig.o roccurs.o dbinfo.o
local.o   -L. -L/usr2/ph/sr
c/lib/rdc/ -L/usr2/ph/src/../lib/  -lodbc32 -lboost_regex -lph2ax  -Wl,--exp
ort-
all-symbols

And this to link my program ...

g++ -Wall -g -O0 -I/usr2/ph/src/../include -I/usr2/ph/src/lib/rdc -I$ORACLE_
HOME
_CYG/oci/include -I. -o rscreen
rscreen.cc -L. -L/usr2/ph/src/lib/rdc/ -L/usr2/p
h/src/../lib/  -lodbc32 -lboost_regex -lph2ax   -L. -lcxxdll

I'm still puzzled by gdb losing track of which source line it is on, not so
much for its own sake but just because it is making it harder to get to the
bottom of what is going on.

Sorry to go on at length - its hard to find the right balance between
brevity and ommission.

Thanks in anticipation,

Dan



> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Dan Osborne
> Sent: 28 September 2004 14:33
> To: 'Cygwin@Cygwin. Com'
> Subject: RE: Program exited with code 0303000
>
>
> >   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?
>
> Well I was actually using -ggdb3 but I tried -g -O0 and it made no
> difference. I think the add_var line is spurious as there is no
> __cxa_rethrow in otlv4.h
>
> >
> >   Hmm.  Have you properly used 'throws XXX' declarations on all
> > the function
> > prototypes that need them?
> >
>
> Err, no there aren't any - I'll add them and see if it helps.
>
> > > 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.
>
> Yes, there's a catch (...) so I'll work on those throws clauses.
>
> Oh and the throw is in a shared library with the catch in my main if that
> has any bearing.
>
> Thanks,
>
> Dan
>
>
> --
> 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/
>

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.768 / Virus Database: 515 - Release Date: 22/09/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.768 / Virus Database: 515 - Release Date: 22/09/2004


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