Re: Disappointed with XCode debugging
Re: Disappointed with XCode debugging
- Subject: Re: Disappointed with XCode debugging
- From: Ricky Sharp <email@hidden>
- Date: Sun, 18 Apr 2004 08:49:46 -0500
On Apr 18, 2004, at 12:41 AM, Eric Albert wrote:
On Apr 17, 2004, at 11:24 PM, Ricky Sharp wrote:
It seems that if you have local variables in registers, the values
column doesn't show the correct value. Thus, I got rid of the
register keyword and could then see the correct values. Will
definitely file a bug soon on this.
While you should definitely file a bug on this, it's actually good
that you got rid of the 'register' keyword. With a modern C/C++
compiler, that typically produces worse optimization than the compiler
will on its own.
(I'd guess, by the way, that register-declared variables simply work
rather poorly with the compiler's generation of debugging information.
But that's just a guess.)
Thanks for the tip. The register keyword was just an old habit. But
I'll definitely remove all traces of it from my codebase.
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.
Forgot to mention that, sorry. I turned ZeroLink and Fix and Continue
off.
-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. 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.
All my factory methods do initialize any static arrays.
The Initialize method I get the crash (inside QueryTechnologies) is
basically:
void CTechMgr::Initialize (void)
{
BlockZero (sTechList, sizeof (CTechnology*) * kNumTechs);
LoadTechnologies(); <- fills sTechList
QueryTechnologies(); <- iterates over sTechList and calls IsAvailable
against each tech.
}
I do have various class data that I do not initialize though inside of
any method, so I'll definitely check the link order.
___________________________________________________________
Ricky A. Sharp mailto:email@hidden
Founder & President
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
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.