2020-07-13 02:36 BST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002177NetSurf[All Projects] Generalpublic2015-03-10 23:45
ReporterMichael Drake 
Assigned ToMichael Drake 
PlatformanyOSanyOS Versionany
Product Version3.2 
Target Version3.3Fixed in Version3.3 
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.
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
Attached Files

related to 0002167closedChris Young Find in page hangs on long pages 

Michael Drake


Michael Drake (administrator)

Is this fixed? Or any better?

The LibDOM stuff may be a red herring.
Chris Young


Chris Young (developer)

With CI#2038 that sf.net page now overflows the 1MB stack I've given NetSurf so, um, worse?
Michael Drake


Michael Drake (administrator)

Can you track down the last version where it worked without excessive stack usage?
Chris Young


Chris Young (developer)

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?
Chris Young


Chris Young (developer)

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.
Daniel Silverstone


Daniel Silverstone (administrator)

There's substantial stack usage as a self-recursion through two paths in box_at_point()


#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
Chris Young


Chris Young (developer)

This page uses nearly 600K of stack: http://www.yoursinclair.co.uk/csscgc/csscgc.cgi?year=2008
Daniel Silverstone


Daniel Silverstone (administrator)

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.
Chris Young


Chris Young (developer)

It's only when I wave the mouse around on the page.
Michael Drake


Michael Drake (administrator)

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.
Michael Drake


Michael Drake (administrator)

I guess the box_at_point stack usage is a different issue to the libdom stack issue that was fixed.
Chris Young


Chris Young (developer)

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.
Vincent Sanders


Vincent Sanders (administrator)

Confirmed fixed in 3.3 release

-Issue History
Date Modified Username Field Change
2014-07-28 19:01 Michael Drake New Issue
2014-07-29 16:26 Vincent Sanders Status new => confirmed
2014-07-30 11:12 Chris Young Relationship added related to 0002167
2014-07-31 00:01 Michael Drake Note Added: 0000425
2014-07-31 00:20 Chris Young Note Added: 0000426
2014-07-31 12:09 Michael Drake Note Added: 0000427
2014-07-31 19:12 Chris Young Note Added: 0000428
2014-07-31 19:17 Chris Young Note Added: 0000429
2014-08-03 13:48 Daniel Silverstone Note Added: 0000431
2014-08-26 23:40 Chris Young Note Added: 0000454
2014-08-27 01:59 Daniel Silverstone Note Added: 0000455
2014-08-27 07:48 Chris Young Note Added: 0000456
2014-08-31 16:38 Michael Drake Note Added: 0000463
2014-08-31 17:26 Michael Drake Assigned To => Michael Drake
2014-08-31 17:26 Michael Drake Status confirmed => assigned
2014-08-31 20:14 Michael Drake Note Added: 0000464
2014-08-31 22:49 Chris Young Note Added: 0000465
2014-09-01 08:03 Michael Drake Status assigned => resolved
2014-09-01 08:03 Michael Drake Resolution open => fixed
2014-09-01 08:03 Michael Drake Fixed in Version => 3.3
2014-09-01 08:03 Michael Drake Target Version => 3.3
2015-03-10 23:45 Vincent Sanders Note Added: 0000766
2015-03-10 23:45 Vincent Sanders Status resolved => closed
+Issue History