[Webkit-unassigned] [Bug 18282] WebKit crashes with deeply nested divs

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=18282


Eric Seidel <eric at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eric at webkit.org




--- Comment #17 from Eric Seidel <eric at webkit.org>  2009-11-30 22:42:43 PST ---
(In reply to comment #16)
> > No new tests. (OOPS!) will cause the commit to fail.
> I left it in there on purpose, as I figured you would come back wanting me to
> add tests for this commit -- just wanted some input on how I should reasonably
> add tests for this.
> 
> > The parsing case could be made quick by caching the current level of the parse tree.
> How exactly can that be accomplished? I'm not familiar with this.  (a pointer
> to some reading material is fine)

http://trac.webkit.org/browser/trunk/WebCore/html/HTMLParser.h#L162

the "block stack" might also be able to cache this information, I'm not sure.

> > Speakign of which, what platform would use this?
> Embedded devices with small maximum stack size -- specifically, in my case,
> Nokia S40 phones.  Currently, since S40 phones don't have process separation,
> if the stack overflows, it causes the phone to reset.  I want to prevent that
> from happening.  Under S60 phones the maximum stack is also relatively small,
> but when stack is exceeded it just takes down the browser, not the OS.
> Under Android, iPhone/iPod touch, and also desktop webkit-based browsers, this
> bug can exhibit itself, but, since the maximum stack size is quite large, the
> element depth to reproduce the bug is ludicrously large -- on the order of
> 100,000 elements deep, therefore it isn't really a big deal on those browsers
> -- users would have long since hit the stop button before the problem would
> manifest itself.

OK, that makes a lot more sense.  I can see how devices could be more sensitive
to this and might want to make the speed tradeoff to prevent bringing down the
whole OS.

I think you still want to optimize the HTML parsing case if possible, but I
think your approach of using a stack crawl instead of caching the value on Node
is probably the right one.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.