patch for oft-seen crash in HTMLTokenizer::notifyFinished

[John Sullivan]

On Dec 16, 2003, at 12:41 PM, Dirk Mueller wrote:

> On Tuesday 16 December 2003 20:38, John Sullivan wrote:
>
>> We had many reports of crashes with the same backtrace.
>
> ... which is?

The last few frames were:

  #0   0x965be058 in HTMLTokenizer::notifyFinished(khtml::CachedObject*) 
(HTMLTokenizer::notifyFinished(khtml::CachedObject*) + 456)
  #1   0x965dffec in khtml::CachedScript::checkNotify() 
(khtml::CachedScript::checkNotify() + 92)
  #2   0x965dff5c in khtml::CachedScript::data(QBuffer&, bool) 
(khtml::CachedScript::data(QBuffer&, bool) + 236)
  #3   0x9656fb00 in khtml::Loader::slotFinished(KIO::Job*) 
(khtml::Loader::slotFinished(KIO::Job*) + 320)

>
>> One almost-always-reproducible one was:
>
> Doesn't look reproducible to me. I'm more worried about how you were 
> able to
> trigger it.
>
> As far as I can interpret the patch, it seems that notifyFinished() is
> recursing into itself during script execution, or that in your 
> codebase there
> is another place that dequeues external scripts. The second case would 
> be
> wrong, the first one very weird. It looks to me like scripts would be
> executed out of order then, which is a bug.

It could be that there is some fundamental ordering issue remaining. 
The almost-reproducible case was elusive in that trying to debug it 
with breakpoints or to a lesser extent printfs would prevent the bug 
from occurring, so there does seem to be a timing-related component. No 
other code was calling dequeue() when the bug was occurring, but it's 
possible that the cachedScript linked list was being deconstructed in 
some more manual fashion.

John