[omniORB] Crash on using nil reference

[Duncan Grisby]

On Wednesday 9 May, "Tim Ward" wrote:

> Trying to release the reference too many times inside an exception handler
> went completely haywire, ending up throwing a sequence of access violation
> exceptions until I ran out of stack.
> 
> Really, I'm *not* impressed. Surely the whole point of a smart pointer is
> that it handles this sort of resource release error in a *vastly* more
> helpful manner than just crashing inside some obscure runtime library code
> to which Microsoft don't release the sources?

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.

omniORB does in fact try to print an error message if you call
release() too many times, but you only get it if you're lucky enough
that the object's memory is still there after it has been
deleted. It's not omniORB's fault if Windows chooses to get itself in
a state when you access deleted memory. On a Unix platform, you'd
probably get a core dump.

This is the sort of bug which a memory bounds checker would flag. In
fact, for this particular problem, we can add a debugging flag to
omniORB which makes it refrain from deleting object references when it
should. That would leak memory, of course, but it would mean that the
error message about too many release()s would be reliable. Obviously
you wouldn't want to turn the option on in production code.

In the absence of a debugging flag, you can compile a leaky version of
omniORB by commenting out line 392 of
src/lib/omniORB2/orbcore/omniInternal.cc, inside releaseObjRef().

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --