Date:	Sun, 24 Jun 2001 10:36:24 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	djgpp AT delorie DOT com
Subject:	Re: Strange behavior of compiler.
In-Reply-To:	<3b351bd7.105078895@news.primus.ca>
Message-ID:	<Pine.SUN.3.91.1010624103544.13700D-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Sat, 23 Jun 2001, Graaagh the Mighty wrote:

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

Speculations, speculations...

Simply run the program under GDB and see what it _really_ does.
Chances are, you will see the offending code in no time, or at least
some new evidence will show up that will shed some light on the
problem.

- Raw text -