All users were logged out of Bugzilla on October 13th, 2018
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20060508 Firefox/126.96.36.199 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20060508 Firefox/184.108.40.206 Try this URL http://www.google.com/url?sa=t&ct=res&cd=3&url=http%3A%2F%2Fwww.bzzt.net%2F~wxwidgets%2Fxmldocs%2Fclasses.xml.backup&ei=6bKLRJznIbOQiAGS_PDLCw&sig2=9xssOVeyAOYwg_2RdabPEQ Firefox will hang. Process Manager shows Firefox rapidly consuming all RAM in system. Reproducible: Always Steps to Reproduce: see above Actual Results: Firefox hung while consuming all my memory. Had to kill it. Expected Results: Not that. I have no clue what the above link actually provides, I found it in a Google search.
BTW, that happens even in safe mode. Try this URL too, which is degooglefied http://www.bzzt.net/~wxwidgets/xmldocs/classes.xml.backup Funny, a similar bug happens in Internet Explorer (consuming all memory). This must be one heck of a monster XML file.
This sounds like bug 197956 ; can you check if it's a dupe? (FWIW, Content-Length: 3255812 and the XML does look pretty shallow)
It *could* be a dupe of bug 197956 - but I'm not sure. My machine paused for a few seconds, but otherwise had no problem choking down that 700kb XML file in Firefox 220.127.116.11. I do have 2GB of RAM, but it really didn't get much over 100MB with the file from bug 197956 With the URL I provided, memory usage shot over 600MB, and at that point, kind of came to a crawl. I imagine the memory space was hugely fragmented at that point, 'causing the slowdown. But it did continue to consume memory, even at the slower rate, while becoming completely unresponsive. As for a fix... I could see how it might not even really be a bug, technically. It would be nice if Firefox would give me a warning that this giant XML file might be too heavy a load to display, are you sure you want to continue? I actually don't care about that giant XML file being resolved. I just happened to step on this landmine from a Google search that didn't really provide me a warning of what I was getting into...
i don't see a talkback incident id, so i'm going to assume you mischaracterized your report.
Severity: critical → major
Summary: trying to view XML (I think) produced repeatable crash which consumes all memory → trying to view XML (I think) produced repeatable slow performance which consumes all memory
Assignee: nobody → xslt
Component: General → XSLT
Product: Firefox → Core
QA Contact: general → keith
Version: unspecified → Trunk
I'm not really sure what to do with this bug. I guess we could set some arbitrary limit to the size of the document where we will not perform the transformation but rather just show some message to the user that it is too big. However the useful such limit will vary vastly from computer to computer, and from year to year. What we possibly do is to measure wall-clock time during the transformation and abort if it takes too long. We have considered this for normal PI transformations where we would like to 'come up for air' every so often for longrunning transformations. Come to think of it. I think that would be the right fix here. So I'm going to mark this INVALID (since we do in fact not crash or hang indefinitely).
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.