Re: test if a pointer is pointing to a valid object or not?
Re: test if a pointer is pointing to a valid object or not?
- Subject: Re: test if a pointer is pointing to a valid object or not?
- From: "Alastair J.Houghton" <email@hidden>
- Date: Wed, 29 Oct 2003 11:52:55 +0000
On Wednesday, October 29, 2003, at 11:28 am, p3consulting wrote:
>
> On Wednesday, October 29, 2003, at 08:50 am, p3consulting wrote:
>
>
>
>> 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.
>
>
>
>
in fact no OS calls are needed since
>
----------------------------------------------------------------
>
high address | command line args and env variables |
>
|--------------------------------------------------------------|
>
| stack |
>
| growing down |
>
| |
>
| |
>
| growing up |
>
| heap |
>
----------------------------------------------------------------
>
| uninitialized static data |
>
----------------------------------------------------------------
>
| initialized static data |
>
----------------------------------------------------------------
>
| program text |
>
low
>
address
>
----------------------------------------------------------------
That memory map may have been accurate for historic UN*X, but it's a
gross over-simplification nowadays. It's quite common for malloc()
implementations to allocate page ranges from the virtual memory system
by using mmap() (or similar), rather than sbrk(), in which case there
can be many separate regions of heap, separated by inaccessible pages.
Also, it's quite possible to use separate stacks allocated from the
area you've labelled as "heap" (I'm willing to bet that the threading
implementation does exactly that).
You still need to do OS calls, or attempt to access it and catch
SIGSEGV and SIGBUS.
>
>> 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.
>
read my post until the end we should clear freed memory before
>
trying to write just a routine
>
and as you state in your own post this is controlled by malloc
>
environment variables (MallocScribble in this case)
>
still a problem ?
You didn't say that originally; you just said that it would make
"writing the loop searching for the topmost isa a little bit easier to
write". Plus you shouldn't enable MallocScribble apart from for
debugging. There are other, better ways to detect method calls on
released objects if you're going to use built-in debug features
(NSZombieEnabled, for example).
>
> 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
>
of course such a routine should not be used to know if a pointer on an
>
object is still on the original one that's a totally different
>
debugging problem and is not what the original poster was asking
OK, he didn't say it explicitly, but of course that's what he meant. A
routine that will tell you that you might have an Objective-C object
but not whether it's the one you expected it to be is clearly useless.
>
> 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).
>
>
>
>
More than a malloc heap is not a problem they are all in the same
>
memory area between the lowest address used by the stack and the top
>
most address used by unitialized data
But they aren't necessarily contiguous in that area; they may very well
be gaps in the memory map (in fact, there probably are, because it
makes the heaps easier to grow, and you'd want gaps surrounding
threads' stacks so you can detect stack overrun).
>
We are not trying to know if the pointer is in the "right" heap,
I never said we were. But it's another flaw in your method.
>
we are trying to answer "is this a pointer on Objective-C object"
Which, as I've said repeatedly, isn't possible. The best you can do is
say that it *might be* a pointer to an Objective-C object, but you
can't guarantee that it's the pointer that the programmer expected. To
give an extreme example, I could build something that looked like an
Objective-C object on the stack. It could even work like one, but would
probably crash if -dealloc ever ran. Your routine would almost
certainly misidentify it as valid, especially if it's running in a
separate thread (because as I already pointed-out, thread stacks will
very likely look like heap, given your simplistic memory map).
>
> So, as I said before, it won't work. You can't do this.
I'm sticking with my opinion. It isn't possible, and you're just trying
to argue your way out of a corner. Besides, as I've also said, there
are other, better ways to achieve similar results if you're debugging
code.
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.