View Revisions: Issue #441
[ All Revisions ] [ Back to Issue ]
| Summary | 0000441: Indirect document self-reference badness | ||
|---|---|---|---|
| Revision | 2013-12-23 14:37 by Vincent Sanders | ||
| Additional Information | jmb202 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 |
||
| Revision | 2007-02-07 18:40 by cjt02 | ||
| Additional Information | jmb202 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 |
||