On Oct 26, 2005, at 12:15 PM, Eric Schlegel wrote:
Well, my first guess would be that you have over-released some
object that was pulled from the app's Info.plist dictionary (via
CFBundleGet<something>), and that this is causing CF to crash later
when it tries to access an object that should be valid but is
actually dead.
You might try using the CFZombieLevel environment variable (search
developer.apple.com for more info) to disable deallocation of
released objects, see if that makes the crash go away, and then you
might be able to track down the object being overreleased.
Eric,
I think I was able to set this environment variable (to 0x00000010),
and run but no luck. Crashing in same place. MallocDebug only put
up a dialog and said it crashed while trying to access 0xdeadbeef -
which seems like an allocation issue to me as well. I just don't
understand why this is happening though. So, I started stepping
through my init sequence, and noticed that there were two CFRelease
calls that I came across BEFORE the crashing MenuManager code.
Skipping over both of them in the CW Debugger lead me to a
successfully running MachO app - complete with document window and
all!!!
So, here's the code that WORKS in CFM and FAILS in MachO:
// extract type and creator codes from it
UInt32 auxCreator;
::CFBundleGetPackageInfo(auxAppBundle, NULL, &auxCreator);
StResource appRes(auxCreator, (ResIDT)0); // could throw
mAppResFile = ::HomeResFile(appRes.Get());
// cleanup (FAILS in Mach-O) ##############################
#if TARGET_RT_MAC_CFM
::CFRelease(auxAppBundle);
#endif
What's the right thing to do here - release or not??? Is this a bug
in my logic (and ignored in CFM) but brought to the surface in MachO?
THANKS to all who helped!
Mark
--
Mark D. Gerl, email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
