delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1998/10/08/13:13:14

Date: Thu, 8 Oct 1998 19:26:56 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Ilya Ryzhenkov <orangy AT inetlab DOT com>
cc: djgpp workers list <djgpp-workers AT delorie DOT com>
Subject: Re: DLM v2.0 soon! ;))
In-Reply-To: <361CEFE8.E1BE795D@inetlab.com>
Message-ID: <Pine.SUN.3.91.981008191805.2751A-100000@is>
MIME-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com

On Thu, 8 Oct 1998, Ilya Ryzhenkov wrote:

> Unhandled exception is not the only reason of SIGABRT, so I should
> trace back the stack to find if it was caused by call to throw and
> it is not as easy in DLM environment.

Why ``trace back the stack''?  The stack dump already shows that SIGABRT 
was raised by `throw', no?

> And there is a pitfall - 
> SIGABRT can be raised, for example, by exception handler and there
> is no way to distinguish between this two events. Sure, there is a 
> way but it is not so wonderful coding ...

You could install a SIGABRT handler that unwinds the stack like 
dpmiexcp.c does, and looks at the address of the function that rased 
SIGABRT.  If that is `throw', print a suitable message and die.

> Isn't it more clear to get
> "Abort! Unhandled exception at ...blah-blah..."
> and print trace back _from the point of exception throw_ ?

The traceback printed by the default handler includes the point where the 
exception was thrown.  It is just not the topmost EIP in the traceback, 
but that is hardly a problem, since the point you are looking for should 
be the second EIP from the top, if I understand correctly.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019