MantisBT - NetSurf |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0002177 | NetSurf | [All Projects] General | public | 2014-07-28 18:01 | 2015-03-10 23:45 |
|
| Reporter | Michael Drake | |
|---|
| Assigned To | Michael Drake | |
|---|
| Priority | normal | Severity | major | Reproducibility | always |
|---|
| Status | closed | Resolution | fixed | |
|---|
| Platform | any | OS | any | OS Version | any |
|---|
| Product Version | 3.2 | |
|---|
| Target Version | 3.3 | Fixed in Version | 3.3 | |
|---|
| Fixed in CI build # | |
|---|
| Reported in CI build # | |
|---|
| URL of problem page | http://libxad.cvs.sourceforge.net/viewvc/libxad/libxad/portable/clients/LhA.c?view=markup |
|---|
|
| Summary | 0002177: Excessive stack usage |
|---|
| Description | NetSurf 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 Reproduce | Visit a page, especially one with lots of elements. |
|---|
| Tags | No tags attached. |
|---|
| Relationships | | related to | 0002167 | closed | Chris Young | Find in page hangs on long pages |
|
| Attached Files | |
|---|
|
Notes |
|
|
|
Is this fixed? Or any better?
The LibDOM stuff may be a red herring. |
|
|
|
|
|
With CI#2038 that sf.net page now overflows the 1MB stack I've given NetSurf so, um, worse? |
|
|
|
|
|
Can you track down the last version where it worked without excessive stack usage? |
|
|
|
|
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? |
|
|
|
|
|
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. |
|
|
|
|
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 |
|
|
|
|
|
|
|
|
|
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. |
|
|
|
|
|
It's only when I wave the mouse around on the page. |
|
|
|
|
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. |
|
|
|
|
|
I guess the box_at_point stack usage is a different issue to the libdom stack issue that was fixed. |
|
|
|
|
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. |
|
|
|
|
|
Confirmed fixed in 3.3 release |
|