Date: Sun, 24 Jun 2001 10:36:24 +0300 (IDT) From: Eli Zaretskii 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.