Re: Bug in DOMStringHandle::operator delete() causes crashes

[Rick Byers <ri...@quack.com>]

Andy Heninger wrote:
> 
> > I've traced through it and when all my DOMParseres gets destroyed,
> > gLiveStringHandleCount goes down to 0 and that terminate code DOES
> > DEFINANTLY get called.  Just setting a breakpoint in there makes it
> > obvious that the code isn't getting called only at terminate time as the
> > breakpoint is triggered over and over again.  Which strings specifically
> > "should remain until terminate() is called"?  I couldn't seem to find
> > any that were gaurenteed to be around.
> >
> 
> It sounds like you've checked this more carefully than me.  And that
> fixing things so that DOMString behaves as the documentation says ought to
> be done.
 
I see 2 different ways to fix this (DISCLAMER: I haven't had a chance to
look at the 1.3 code yet - so I'm assuming, as Andy says, that there
aren't any changes that affect this problem):

1) Extend the mutex lock in DOMStringHandle::operator delete to cover
the whole function.  Then move the call to DOMStringTerminate into
XMLPlatformUtils::Terminate (probably right before or right after the
call to XMLString::termString).  This has the advantage that if no
strings are being used, the memory for the string handle pool is
released.

2) Move all the code in the if(DOMString::gLiveStringHandleCount == 0)
block into DOMStringTerminate and then just call DOMString terminate
from XMLPlatformUtils::Terminate.  This has the advantage that if you're
constantly creating and destroying parsers, you won't keep allocating
and freeing the string handle pool block.

I think #2 would be better, thoughts?.  What are the dependancies on
DOMStrings?  Should DOMStringTerminate be called before or after
XMLString::termString?  Should we set some flag that says
DOMStringTerminate has been called which is checked by
DOMStringHandle::operator new to ensure we're not attempting to create
any strings after calling terminate just as a sanity check?

Rick