Re: Disappointed with XCode debugging
Re: Disappointed with XCode debugging
- Subject: Re: Disappointed with XCode debugging
- From: Jens Miltner <email@hidden>
- Date: Sun, 18 Apr 2004 10:03:29 +0200
Am 18.04.2004 um 07:41 schrieb Eric Albert:
On Apr 17, 2004, at 11:24 PM, Ricky Sharp wrote:
I think I've found the reason for my app's crashing, but I really
don't understand what I'm seeing.
I have an abstract base CTechnology class which implements certain
basic methods and has a few pure virtual methods.
There are then several derived classes; one to serve as a wrapper
around some technology (e.g. QuickTime).
Here's the strange part...If I view the type of the aTechnology
variable, half of the time, it shows that the type is a CTechnology*.
The other half of the time, it shows the derived class (e.g.
CQuickTime*). Whenever I call IsAvailable in situations where the
type given me is a CTechnology*, I get a crash. Probably because
it's issuing that method against the base class, but the base
classes' method is pure virtual and thus NULL?
I've never seen anything like this before in any build environment.
I've verified that RTTI is on (Enable C++ Runtime types is ON in my
target settings).
Has anyone seen this type of behavior?
Not directly, but I'll toss out a few guesses:
-Try turning ZeroLink off. With it on, the load order of various
modules in your executable may be different from what you'd typically
expect, and your variables might not be getting initialized correctly.
-Double-check the way your static arrays get initialized. The order
of static variable initialization across modules in a Mach-O
executable may be different from what you expect in CFM.
Furthermore, having two different sections of global initialization
depend on each other is bound to lead to trouble, as the order of
global/static initialization is explicitly not guaranteed. In fact,
I've been hit by this before without even changing compiler vendors due
to either some rearrangement of link order or due to a change in
Metrowerk's compiler/linker technology.
If you have interdependent static objects, even the rule "a static
object is guaranteed to be intialized when the module where it's
defined is first entered" may not hold true...
The lesson I've learned is that if you need your variables/objects to
be initialized at a specifc point, don't rely on global "pre-main"
allocation/initialization!
Of course, if your static arrays get initialized by your factory
method the first time it's called (or they're otherwise initialized by
a method call rather than their static declaration outside a method in
a source file), this won't be an issue.
</jum>
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.