Mail Archives: djgpp/2001/06/23/19:00:25.2
On 21 Jun 2001 09:46:43 GMT, Hans-Bernhard Broeker
<broeker AT physik DOT rwth-aachen DOT de> sat on a tribble, which squeaked:
>Graaagh the Mighty <invalid AT erehwon DOT invalid> wrote:
>> On Thu, 21 Jun 2001 07:58:54 GMT, invalid AT erehwon DOT invalid (Graaagh the
>> Mighty) sat on a tribble, which squeaked:
>
>>>I have more information. On a hunch I looked at the changes. There was
>>>a bug in one of the debugging bits I added that would in fact have
>>>jumped into never-never land
>
>A bug in a *printf* that would *jump* somewhere? Sorry, but you'll
>have to explain what that's supposed to mean. No printf in the world
>jumps anywhere, like that.
There was an associated set_gfx_mode, and allegro wasn't initialized
at that point. Nonetheless, this shouldn't have caused the call to the
function *containing* the set_gfx_mode to branch directly to nowhere!
>What makes you so sure it hasn't?
It wasn't in the freaking traceback?
>One possible explanation: if 'bar' contains a jump (assembly jmp or C
>function call) into never-never-land, the crash will happen before a
>proper stack frame has been set up for the new 'function', which may
>*very* easily mean that the stackframe unwinding machinery can't see
>that this call was not coming from 'main', but from 'bar'.
The jump would have to be right at the start of the function, before
it even did whatever establishes new stack frames (reading its own
arguments off the stack?). I doubt this can occur without
-fomit-frame-pointer (which I wasn't using for that compile), and
certainly not if there are statements with side effects before the
jump in the function, which the optimizer cannot move. Which there
were.
--
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 -