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: "Dan Osborne" <dan DOT osborne AT ramesys DOT com>
To: "'Cygwin AT Cygwin. Com'" <cygwin AT cygwin DOT com>
Subject: RE: Program exited with code 0303000
Date: Tue, 28 Sep 2004 14:33:09 +0100
Message-ID: <004401c4a55f$b1e46cf0$eb88510a@internal.specialist.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <NUTMEG6kjCmtBcj9ZVL00000124@NUTMEG.CAM.ARTIMI.COM>
X-Ramesys-Professional-Services-MailScanner-Information: Please contact the ISP for more information
X-Ramesys-Professional-Services-MailScanner: Found to be clean
X-Ramesys-Professional-Services-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-0.3, required 5, IN_REP_TO -3.38, PORN_10 0.64, SUBJ_HAS_UNIQ_ID 2.54)
Note-from-DJ: This may be spam

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