Some more debugging questions...
Some more debugging questions...
- Subject: Some more debugging questions...
- From: John Draper <email@hidden>
- Date: Sun, 01 May 2005 17:49:29 -0700
Hi,
I was able to find out that I can stop at a strategic point in the
debugger, then take a snapshot
of the heap each iteration through the loop, and came up with this...
NSCFString = 2794 (94400 bytes)
NSCFString = 2818 (94992 bytes) - gained 24
So I now know that I have gained 24 string objects... so now I want to
find out which
ones I've gained, so I'm going to want to get the addresses of the new
ones I gained.
But the "heap" command doesn't give me individual addresses of the
NSStrings I have
gained. So how do I determine what the actual addresses are, so I can
chase down the
problem?
Like I repeatedly posted over and over again last week, on how I can
display the heap.
I also tried to play with MallocDebug tool application, but want to
also use it in conjunction
with the sourvc level debugger, and not use it in instances where I
have to run my
application without the opportunity to "break" it at a certain point.
So how do I
tell MallocDebug how to take control of a program I'm in middle of
debugging.
Ok, and then I see these entries in the "heap" shell command...
NSZombie_XMLTree = 63 (1008 bytes)
NSZombie_NSMutableRLEArray = 63 (1008 bytes)
NSZombie_NSRegion = 62 (1984 bytes)
NSZombie_NSConcreteAttributedString = 60 (960 bytes)
What are these? Are these instances where they are detached handles?
IE: handles
that are lost and therefore not released? I do have NSZombieEnabled
= YES to get this?
I never allocated NSRegion, or any of these objects excelt XMLTree.
What does this mean?
Does this mean I'm not managing the XMLTree objects properly and I have
allocated
and not released them?
John
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden