[Webkit-unassigned] [Bug 63290] Stack overflow with enormous SVG filter

[bugzilla-daemon at webkit.org]

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





--- Comment #17 from Brent Fulgham <bfulgham at webkit.org>  2014-09-24 09:46:04 PST ---
(From update of attachment 238583)
View in context: https://bugs.webkit.org/attachment.cgi?id=238583&action=review

>> Source/WebCore/rendering/svg/RenderSVGResourceFilter.cpp:81
>> +        return nullptr;
> 
> You could add 100,000 nodes and none contributes to the actual filter chain. The actual filter tree is build in RenderSVGResourceFilter::buildPrimitives. After running the for loop, we know which effects are connected with each other. Currently we don't clean up the builder map though. Only way to know is to go through builder->lastEffect and count the effects recursively after running RenderSVGResourceFilter::buildPrimitives. A trivial way (probably not the best way) is to add a method to FilterEffects that gets a number, increases the number and calls all child filter effects with the same method and you get an actual number at the end.
> 
> Out of curiosity, why did you chose 10k nodes? IMO it could be 500 or less. After all, most filter effects causes a significant amount of computing cycles on their own.

It sounds like your concern is that this arbitrary cutoff here will needlessly prevent building the filter chain if the SVG document has thousands of nodes, but only a small number of filter-related nodes. Do I understand what you are saying?

As for the second section that suggests traversing the filter elements and building the chain before calculating the node count (or depth): won't we be back to the same problem where we exceed stack depth? Or are you suggesting keeping a running count of filter effect depth and breaking out early when we determine we've hit our limit?

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