[omniORB] Crash on using nil reference

[Tim Ward]

-----Original Message-----
From: Stephen Crawley <crawley@dstc.edu.au>
>Tim Ward writes:
>> From: Sai-Lai Lo <S.Lo@uk.research.att.com>
>
>> >And how does one retire the mapping of pointers and reference counts?
>>
>> One doesn't. It's a static data member in the smart pointer class, so its
>> lifetime is the lifetime of the application.
>>
>> An entry in the map is deleted when the use count goes to zero; a
subsequent
>> attempt to decrement the use count will search the map for the pointer,
fail
>> to find it, and complain that the pointed-to entity has already been
>> released.
>
>There is a flaw in this.  The memory manager cannot reallocate the
>memory associated with a pointer when its reference count reaches zero.
>If it did, you would find that pointers to now dead objects would spring
>back into life, pointing at different objects.

Yes, this can happen in theory.

>This defeats your
>checking.

No, it only defeats it in the 0.0001% of cases when it actually happens. You
need all the following to run into this problem:

(1) There's a bug in your code such that a particular pointer is not
properly forgotten after it has been freed.
(2) You are unlucky enough that exactly the same address gets re-allocated
to exactly the same type of object.
(3) You use the pointer again after the reallocation.
(4) Your application is sufficiently deterministic that every time you run
it the same address gets freed and reused in the same way (if this doesn't
hold then you'll pick up the bug on a later run).
(5) The same bug never involves some other pointer (which wasn't
fortuitously reallocated to the same type of object) being used after it was
freed.

I believe that I have never seen this happen in practice; I have certainly
seen such a mechanism save lots of money by finding bugs.

Tim Ward
Brett Ward Limited - www.brettward.co.uk