Re: NSDebug.h and frame pointers
Re: NSDebug.h and frame pointers
- Subject: Re: NSDebug.h and frame pointers
- From: Chris Kane <email@hidden>
- Date: Wed, 7 Nov 2001 15:46:40 -0800
The problem sometimes with these can be that a stack frame gets
corrupted by something, and then walking back up the call stack with
these functions then causes the pointer indirections to fly off into bad
memory and crash a program.
However, NSReturnAddress() is crashing even in a simple test program
(crashes in both 10.0 and 10.1). The code for these functions hasn't
changed in years. What does seem to be different is the compiler code
generation when optimization is turned on has improved, and frame setup
in some of the functions involved (the internal functions they call in
their implementation) is now being omitted by the compiler when
optimizing (even with -O1). This falls into the problem implied by the
comments: "The behavior of these functions is undefined in the presence
of code which has been compiled without frame pointers." Unfortunately,
the implementation of the functions themselves are being compiled in
some cases without frame pointers, which causes them to pull the wrong
values/locations off the stack as the "previous frame" pointers, and
they go off into bad memory (since the functions have to go back up
through the frames introduced by function calls within the
implementation).
The compiler built-in functions __builtin_frame_address() and
__builtin_return_address() can be used in some situations, and these
take a CONSTANT integer which is the number of frames to go "up" from
the current stack pointer. Unfortunately, these ONLY take a constant
integer -- you can't pass a variable, as you would when looping, for
example, and there's no function to get the previous frame pointer given
a frame pointer either. A great big switch statement in a function
taking a variable for the # of frames is one possible solution (the
cases of the switch each passing in the constant for that case into
those builtins). However, such code still needs to make sure that frame
pointers aren't omitted by optimization.
Chris Kane
Cocoa Frameworks, Apple
On Thursday, October 25, 2001, at 07:27 AM, Girard Iglesias wrote:
Hi,
What did happen to some function of NSDebug.h, for example, they make my
app crashing, what are the replacements?
/**************** Stack processing ****************/
FOUNDATION_EXPORT void *NSFrameAddress(unsigned frame);
FOUNDATION_EXPORT void *NSReturnAddress(unsigned frame);
// Returns the value of the frame pointer or return address,
// respectively, of the specified frame. Frames are numbered
// sequentially, with the "current" frame being zero, the
// previous frame being 1, etc. The current frame is the
// frame in which either of these functions is called. For
// example, NSReturnAddress(0) returns an address near where
// this function was called, NSReturnAddress(1) returns the
// address to which control will return when current frame
// exits, etc. If the requested frame does not exist, then
// NULL is returned. The behavior of these functions is
// undefined in the presence of code which has been compiled
// without frame pointers.
FOUNDATION_EXPORT unsigned NSCountFrames(void);
// Returns the number of call frames on the stack. The behavior
// of this functions is undefined in the presence of code which
// has been compiled without frame pointers.
Regards
Girard
_______________________________________________
cocoa-dev mailing list
email@hidden
http://www.lists.apple.com/mailman/listinfo/cocoa-dev