MantisBT - NetSurf
View Issue Details
0000441NetSurf[All Projects] Generalpublic2007-02-07 18:402015-03-10 23:37
Reportercjt02 
Assigned ToJohn-Mark Bell 
PrioritynormalSeverityminorReproducibilitysometimes
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version3.3 
Fixed in CI build #
Reported in CI build #
URL of problem page
Summary0000441: Indirect document self-reference badness
DescriptionThis site:

http://pilot.citizendium.org/

causes NS to grab more and more memory until it fails (sometimes with an out-of-memory message, sometimes not). Site works in O2 and FF. The only log I have is about 50MB :-(

NS 6/2/07; RO 5.11, 512MB
Additional Informationjmb202 added a note on Sat May 5 17:23:13 2007

Logged In: YES
user_id=906191
Originator: NO

Downgrading from 1.0 RC - the current fix is good enough for the time being.

cjt02 added a note on Wed Mar 21 10:24:25 2007

Logged In: YES
user_id=1397835
Originator: YES

Thanks for the provisional fix, and for the interesting explanation.

jmb202 added a note on Mon Mar 19 00:31:40 2007

Logged In: YES
user_id=906191
Originator: NO

This may be fixed in the latest version. It's a bit hacky though, and I'm not sure I like the fix.

Summary of the issue:

The page in question includes itself (probably indirectly through a CSS file) as a CSS document. NetSurf detects that the content type is not permissible in the relevant context and thus ignores the "stylesheet". It does this by simply having the owning content remove itself from the user list of the bad one; leaving the bad content alone for content_clean() to have its way with next time it's called. In the meantime, however, the bad content is still being fetched, parsed, etc. As it's the same document, we get some nice recursion going on, which eats memory until there is no more.

Summary of the current workaround:

As the content's in error, once the parent has removed itself from the user list, it explicitly checks to see if there are no further registered users of the content. If there are none, then it forcibly stops the fetch and marks the bad content as being in error. I'm not 100% sure this catches all cases, however, and it certainly doesn't solve the generic issue of indirected self-reference (there are already checks all over the place for direct self-reference, as this is easy to do and fairly common).

Perhaps a more robust solution would be to do the following:

In fetchcache(), traverse the parent content list up to the root. If the URL for the fetch being attempted is encountered, don't bother to fetch at all. This traversal needs to cover all registered users of the immediate parent content.
Unfortunately, this doesn't cater for the case where the server serves up the same document from differing URLs (e.g. when different GET parameters are specified). Quite how we're meant to deal with that, I've no idea at present.

cjt02 added a note on Sun Feb 11 03:49:15 2007

Logged In: YES
user_id=1397835
Originator: YES

OK. It seems intermittent. I got the site to load successfully this afternoon, but it took 2 mins to render the page. Just now it loaded and rendered almost instantly. But after trying to look at another page on the site (just gets a login prompt), I used the back button and provoked the same crash, with DA memory constantly rising until 128MB, then a crash.
 
I did manage to get a log this time, but it appears to be too big to upload (324K, zipped from 14MB). I'll send it to you if you need it.

(Incidentally, NS clips the error message to "Uploaded file must be >20 and ", presumably because it's interpreting the subsequent "<256000 bytes." as a tag.)


tlsa added a note on Sat Feb 10 17:51:12 2007

Logged In: YES
user_id=826159
Originator: NO

We can't reporduce this. Can you check that NetSurf still crashes?

The site may have changed since your report.

cjt02 added a note on Wed Feb 7 18:44:01 2007

Logged In: YES
user_id=1397835
Originator: YES

Forgot to mention: the site doesn't display anything, and you can't quit NS until it crashes of its own accord.

Imported from sourceforge bug http://sourceforge.net/support/tracker.php?aid=1654452 on Tue Dec 10 17:34:12 2013

TagsNo tags attached.
Attached Files

Notes
(0000730)
Vincent Sanders   
2015-03-10 23:37   
Confirmed fixed in 3.3 release

Issue History
2013-12-10 17:41Vincent SandersNew Issue
2013-12-10 17:41Vincent SandersStatusnew => assigned
2013-12-10 17:41Vincent SandersAssigned To => Sourceforge Import placeholder
2013-12-23 14:37Vincent SandersAssigned ToSourceforge Import placeholder => John-Mark Bell
2013-12-23 14:37Vincent SandersReproducibilityhave not tried => sometimes
2013-12-23 14:37Vincent SandersStatusassigned => confirmed
2013-12-23 14:37Vincent SandersResolutionno change required => open
2013-12-23 14:37Vincent SandersDescription Updatedbug_revision_view_page.php?rev_id=793#r793
2013-12-23 14:37Vincent SandersAdditional Information Updatedbug_revision_view_page.php?rev_id=795#r795
2014-11-15 10:42Michael DrakeStatusconfirmed => resolved
2014-11-15 10:42Michael DrakeResolutionopen => fixed
2015-03-10 11:16Vincent SandersFixed in Version => 3.3
2015-03-10 23:37Vincent SandersNote Added: 0000730
2015-03-10 23:37Vincent SandersStatusresolved => closed