MantisBT - NetSurf
View Issue Details
0002177NetSurf[All Projects] Generalpublic2014-07-28 18:012015-03-10 23:45
ReporterMichael Drake 
Assigned ToMichael Drake 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformanyOSanyOS Versionany
Product Version3.2 
Target Version3.3Fixed in Version3.3 
Fixed in CI build #
Reported in CI build #
URL of problem pagehttp://libxad.cvs.sourceforge.net/viewvc/libxad/libxad/portable/clients/LhA.c?view=markup
Summary0002177: Excessive stack usage
DescriptionNetSurf is using an excessive amount of stack

09:16 < tlsa> --------------------------------------------------------------------------------
09:16 < tlsa> n time(i) total(B) useful-heap(B) extra-heap(B) stacks(B)
09:16 < tlsa> --------------------------------------------------------------------------------
09:16 < tlsa> 48 1,840,888,502 106,047,976 92,363,255 11,946,809 1,737,912
09:16 < tlsa> with nsfb
09:16 < tlsa> running this:
09:16 < tlsa> valgrind --tool=massif --stacks=yes ./nsfb http://libxad.cvs.sourceforge.net/viewvc/libxad/libxad/portable/clients/LhA.c?view=markup
09:17 < tlsa> so 1.7 MB stack usage :s


12:49 < tlsa> ahah!
12:49 < tlsa> valgrind --tool=callgrind ./nsfb http://libxad.cvs.sourceforge.net/viewvc/libxad/libxad/portable/clients/LhA.c?view=markup
12:49 < tlsa> turn off cycle detection
12:50 < tlsa> and click on _dom_node_try_destroy
12:50 < tlsa> and fear the insane recursion


13:05 < jmb> well, it really shouldn't be a surprise
13:05 < jmb> see my earlier commentary about libdom refcounting being utterly broken right now
Steps To ReproduceVisit a page, especially one with lots of elements.
TagsNo tags attached.
related to 0002167closed Chris Young Find in page hangs on long pages 
Attached Files

Notes
(0000425)
Michael Drake   
2014-07-30 23:01   
Is this fixed? Or any better?

The LibDOM stuff may be a red herring.
(0000426)
Chris Young   
2014-07-30 23:20   
With CI#2038 that sf.net page now overflows the 1MB stack I've given NetSurf so, um, worse?
(0000427)
Michael Drake   
2014-07-31 11:09   
Can you track down the last version where it worked without excessive stack usage?
(0000428)
Chris Young   
2014-07-31 18:12   
Max stack usage (bytes) after visiting that page, with various versions:
v3.1 - 22220
1893 - 32780
1964 - >1MB
2040 - 33084

So it looks like it is fixed now. Maybe 2038 didn't get the libdom changes?
(0000429)
Chris Young   
2014-07-31 18:17   
Saying that, with some more browsing of random pages I've managed to get it back up to ~500K. I'll try and figure out which page caused that.
(0000431)
Daniel Silverstone   
2014-08-03 12:48   
There's substantial stack usage as a self-recursion through two paths in box_at_point()

E.g.

#30 0x00000000004f0468 in box_at_point (box=0x418db70, x=533, y=285, box_x=0x7fffffffa428, box_y=0x7fffffffa424) at render/box.c:408
#31 0x00000000004f079e in box_at_point (box=0x418ac90, x=533, y=285, box_x=0x7fffffffa428, box_y=0x7fffffffa424) at render/box.c:472
(0000454)
Chris Young   
2014-08-26 22:40   
This page uses nearly 600K of stack: http://www.yoursinclair.co.uk/csscgc/csscgc.cgi?year=2008
(0000455)
Daniel Silverstone   
2014-08-27 00:59   
Can you confirm if the stack usage happens on load, or only if the mouse pointer is inside the render area? The box_at_point stuff only fires if the mouse is over the render area.
(0000456)
Chris Young   
2014-08-27 06:48   
It's only when I wave the mouse around on the page.
(0000463)
Michael Drake   
2014-08-31 15:38   
Chris: Please test with my latest changes. I rewrote box_at_point to use iteration instead of recursion.

Let me know if it's any improvement. Also when did this issue start? box_at_point has used recursion to walk the box tree since forever, so I'm confused by this becoming an issue now.

Also, let me know if there are any side effects, like maybe it's slower (e.g. text selection), my machine's too fast to say. Or perhaps unclickable links that worked before.
(0000464)
Michael Drake   
2014-08-31 19:14   
I guess the box_at_point stack usage is a different issue to the libdom stack issue that was fixed.
(0000465)
Chris Young   
2014-08-31 21:49   
That seems to be fixed. I can't get the stack usuage to budge above 56332 bytes, and I can't see any side effects either.

I have no idea when this started, it may well have always been like it. I only noticed the libdom one because it was manifesting as a reproducible crash, whereas box_at_point would have been quite random.
(0000766)
Vincent Sanders   
2015-03-10 23:45   
Confirmed fixed in 3.3 release

Issue History
2014-07-28 18:01Michael DrakeNew Issue
2014-07-29 15:26Vincent SandersStatusnew => confirmed
2014-07-30 10:12Chris YoungRelationship addedrelated to 0002167
2014-07-30 23:01Michael DrakeNote Added: 0000425
2014-07-30 23:20Chris YoungNote Added: 0000426
2014-07-31 11:09Michael DrakeNote Added: 0000427
2014-07-31 18:12Chris YoungNote Added: 0000428
2014-07-31 18:17Chris YoungNote Added: 0000429
2014-08-03 12:48Daniel SilverstoneNote Added: 0000431
2014-08-26 22:40Chris YoungNote Added: 0000454
2014-08-27 00:59Daniel SilverstoneNote Added: 0000455
2014-08-27 06:48Chris YoungNote Added: 0000456
2014-08-31 15:38Michael DrakeNote Added: 0000463
2014-08-31 16:26Michael DrakeAssigned To => Michael Drake
2014-08-31 16:26Michael DrakeStatusconfirmed => assigned
2014-08-31 19:14Michael DrakeNote Added: 0000464
2014-08-31 21:49Chris YoungNote Added: 0000465
2014-09-01 07:03Michael DrakeStatusassigned => resolved
2014-09-01 07:03Michael DrakeResolutionopen => fixed
2014-09-01 07:03Michael DrakeFixed in Version => 3.3
2014-09-01 07:03Michael DrakeTarget Version => 3.3
2015-03-10 23:45Vincent SandersNote Added: 0000766
2015-03-10 23:45Vincent SandersStatusresolved => closed