Mail Archives: djgpp/2001/06/25/08:00:07.1
On Sun, 24 Jun 2001 10:55:32 +0300 (IDT), Eli Zaretskii
<eliz AT is DOT elta DOT co DOT il> sat on a tribble, which squeaked:
>
>On Sat, 23 Jun 2001, Graaagh the Mighty wrote:
>
>> >No, I blame it on you: it's your bug that caused a GPF inside CWSDPMI.
>>
>> There are clearly two bugs here:
>> 1. My code crashed. Ergo, it has a bug.
>
>Yes.
>
>> 2. CWSDPMI code crashed. Ergo, it has a bug.
>
>No, CWSDPMI didn't crash. Where do you think that message with
>registers come from? CWSDPMI detected the GPF, printed the message,
>aborted the program, then exited.
This is in contradiction to your earlier claim. Earlier you said that
traceback I posted was a CWSDPMI crash instead of a user-code crash,
albeit presumably triggered by a user-code crash.
>When GPF's happen inside CWSDPMI, it usually means that the
>application's memory or exception table is so badly scrogged that it
>doesn't make sense to let the application code run.
The latter is a general description of why we have access protections
and things like SIGSEGV rather than simply letting an errant program
scribble out of bounds. What remains unexplained here is that CWSDPMI
is dying horribly, and this is obscuring the cause of the problem.
In any case, let's drop this argument about whether it's a bug in
CWSDPMI or not if it sometimes blows up when the user code blows up.
Even if it is decided to be a bug and corrected it'll be ages before a
new version is available. So in the meantime, are there any
suggestions as to how to get a meaningful traceback in this case? Not
having a traceback indicating where the program was in its parameter
space when it began to seriously screw up is rather like being
blindfolded...
--
Bill Gates: "No computer will ever need more than 640K of RAM." -- 1980
"There's nobody getting rich writing software that I know of." -- 1980
"This antitrust thing will blow over." -- 1998
Combine neo, an underscore, and one thousand sixty-one to make my hotmail addy.
- Raw text -