Re: cocoa-dev digest, Vol 2 #3103 - 18 msgs
Re: cocoa-dev digest, Vol 2 #3103 - 18 msgs
- Subject: Re: cocoa-dev digest, Vol 2 #3103 - 18 msgs
- From: "Alastair J.Houghton" <email@hidden>
- Date: Wed, 29 Oct 2003 10:12:16 +0000
On Wednesday, October 29, 2003, at 08:50 am, p3consulting wrote:
is there anyway to test if a pointer, that isn't NULL, is pointing to
a valid object or not?
It''s not possible that way because calling isKindOfClass
assume the target is an object
In other words the hypothesis has been used in the
demonstration making it void.
Theory of operation for a IsValidObjectPointer(void *ptr)
function: (may I insist on the "theory" word here)
You can insist on the word "theory" if you like, but it doesn't make
your argument below correct.
1. if p is not a multiple of 4 it''s not a valid mallocated
pointer: reject it
Fair enough. I think the restriction on alignment may actually be more
extreme than this on Mac OS X (8 or perhaps even 16 bytes), but I don't
have the inclination to check right now.
2. check that p is in the memory space (some Unix/Mach/BSD
calls should provide this kind of info) of your process and - if
this is possible - check if it is in the malloc heap
OK, that's fair enough also.
3. if ok then dereferences it (it's now guaranted not to crash
your code with a signal) to get the theorical isa and loop on
that process
(checking if the isa you now have is correctly aligned, in
your memory space etc.)
until you reach the top of the hierarchy that should be a
[NSObject class]
But this is wrong, for three reasons:
1. malloc() and free() don't clear memory. So you could have a pointer
to an object that you have already released, but that is in an area of
memory that has since been given to someone else by malloc(). It will
pass tests 1 and 2, even if you elaborate test 2 to ask whether it is
in the allocated region of the malloc() heap.
2. You can't assume that some area of memory contains a valid object
just because the memory appears to contain a valid isa pointer,
stretching right back to an NSObject at the very top. Perhaps whoever
currently owns that block of memory has cleared or otherwise
initialised some of it, but has left the first four bytes alone for the
moment. Or perhaps the isa pointer was copied there from somewhere
else. You just don't know, and no amount of code is going to tell you.
3. Even assuming that it does contain a valid object, you don't know
that it was the object you originally had a pointer to. The area of
memory may have been re-used by someone else for another, completely
different object. Again, you don't know, and no amount of code will
tell you.
There are some additional problems, including the fact that there can
be more than one malloc() heap on Mac OS X (corresponding to the NSZone
objects in Cocoa), so you'd have to check whether the block was
allocated in any of the currently active heaps. And the fact that not
all objects you might see actually inherit from NSObject (the proxy
objects for DO don't, for example).
Plus, as you say, you'd have to detect cycles, including cycles of more
than length one.
So, as I said before, it won't work. You can't do this.
If you want it for debugging purposes, look in NSDebug.h, which
provides details some flags you can enable to allow you to track down
Cocoa-related memory problems. You can also use the various malloc()
environment variables to examine the behaviour of the memory allocator,
as well as a number of useful tools. See section 3.1.7 of my FAQ, at
http://www.alastairs-place.net/cocoa/faq.txt
for more information on some of these.
Kind regards,
Alastair.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.