www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/05/22/15:56:38

Date: Thu, 22 May 1997 19:12:23 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Calvin French <frenchc AT cadvision DOT com>
cc: djgpp AT delorie DOT com
Subject: Re: __djgpp_exception_table+281
In-Reply-To: <5m01a1$2gcg@elmo.cadvision.com>
Message-ID: <Pine.SUN.3.91.970522191131.29094Y-100000@is>
MIME-Version: 1.0

On 21 May 1997, Calvin French wrote:

> ... means? Kind of a cryptic error message I picked up today, or 
> rather I should say this is what the call frame traceback yields after 
> a gpf. And that's it, it's as if there's nothing else on the call 
> stack. Wierd, I know :-) What does __djgpp_exception_table+281 do?

Not weird at all, and it would be much more clear if you would to post
the entire traceback.  Please do so in the future if you want fast and
efficient help.

In general, `__djgpp_exception_table' is the table of handlers for all
the exceptions supported (at least in theory) by DJGPP.  By default,
most of these handlers point to the default handler, which just prints
the traceback and terminates your program.

As for 281: are you sure it was 281 and not 291?  291 is the offset
where the handler for SIGSEGV lives (see <signal.h> which defines
SIGSEGV to be 291).  The error might mean that your stack is trashed
(try to enlarge it by stubediting, or loo for an array that runs out
of bounds) or that you installed a hardware interrupt and failed to
lock some of the data it touches.

The precise analysis isn't possible without seeing at least the entire
crash traceback.  It is also a good idea to tell just what your
program does.

- Raw text -


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