[omniORB] Crash on using nil reference

[Tim Ward]

From: Sai-Lai Lo <S.Lo@uk.research.att.com>
>>>>>> Tim Ward writes:
>
>> From: Duncan Grisby <dgrisby@uk.research.att.com>
>>>
>>> The semantics of the reference counts are that when the count reaches
>>> zero, the object reference is deleted. After that, any operations on
>>> the object reference are dealing with freed memory, so it's impossible
>>> for the ORB to trap reliably. The fact that you are using _var types
>>> doesn't make any difference.
>
>> Ah, right. (More sophisticated smart pointers keep a map of pointers and
>> reference counts (in debug builds, at least), so after an object has been
>> deallocated the pointer can still reliably and safely spot and report
this
>> without crashing.)
>
>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.

If you've got lots of cpu cycles to waste you can even do a map search every
time the pointer's -> operator is used, so as to trap following deleted
pointers! You can also store filenames, line numbers etc in the map so that
you've got some clues as to whodunnit when things go wrong. All debug build
only stuff, this, one would expect.

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