Closed Bug 609233 Opened 14 years ago Closed 2 years ago

OOM crash in nsIFrame::InvalidateInternal when opening html file, in which JavaScript has created big amount of tables

Categories

(Core :: Layout, defect)

x86
All
defect

Tracking

()

RESOLVED INVALID

People

(Reporter: z.dolezal, Unassigned)

References

Details

(Keywords: crash, hang, testcase)

Crash Data

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24pre) Gecko/20100228 K-Meleon/1.5.4 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 <html> <head> </head> <body> <img name="il62" src="tmp/IL62Checklist.PNG" /> <img name="a" src="tmp/a.PNG" /> <script type="text/javascript"> for ( i = 1; i < 1000; i++) { document.write("<table><tr>"); for ( i = 1; i < 2; i++) { document.write("<TD> $????i</TD>"); } document.write("</tr><//table>"); } str="Need tips? Visit W3Schools!"; str_esc=escape(str); document.write(str_esc + "<br />"); document.write(unescape(str_esc)) document.write("PK") document.images.il62; </script> </body> </html> Reproducible: Didn't try Steps to Reproduce: 1. open html file (see "Details" above) Actual Results: crash I'm not sure about following section "Security" file "a.PNG" has not graphic format, it contains text file IL62Checklist.PNG doesn't exist on specified path
Do you use a Mozilla.org binary build ? The symbols are somehow missing...
(In reply to comment #3) > Created attachment 488021 [details] > Testcase from the reporter > > Do you use a Mozilla.org binary build ? > The symbols are somehow missing... no, I'm using Puppy linux package
Please attach the "a.PNG" file.
(In reply to comment #5) > Please attach the "a.PNG" file. I have tried Mozilla.org binary build and it is still crashing. I think file a.PNG is not problem. It seems that problem is memory exhaustion due to infinite loop in JS - see code below. I am sorry I can't send bigger files(a.PNG) due to internet connection troubles. <html> <head> </head> <body> <script type="text/javascript"> var nTablesCount = 4; for ( i = 1; i < nTablesCount; i++) { document.write("<table><tr>"); for ( i = 1; i < 2; i++) { document.write("<TD> "); } } for ( i = 1; i < nTablesCount; i++) { document.write("</td></tr></table>"); for ( i = 1; i < 2; i++) { } } </script> </body> </html>
With the attached testcase I get the "Unresponsive script" dialog after about 10 seconds. Clicking "Don't ask again" and "Continue" makes it consume 100% CPU and eventually Linux oom-killer kills the process. I don't see any interesting crashes with the testcase.
Severity: critical → normal
Keywords: testcase
Version: unspecified → 3.6 Branch
Reporter, Firefox 4.0.1 has been released, and it features significant improvements over previous releases. Can you please update to Firefox 4.0.1 or later, and retest your bug? Please also create a fresh profile ( http://support.mozilla.com/kb/Managing+profiles), update your plugins (Flash, Java, Quicktime, Reader, etc) and update your graphics driver and Operating system to the latest versions available. If you still continue to see this issue, please comment. If you do not, please close this bug as RESOLVED > WORKSFORME filter: prefirefox4uncobugs
this would have OOM me too. Also locks the UI until unresponsive script, which seemed to have trouble displaying. affects chrome in similar way
Severity: normal → major
Keywords: perf
OS: Linux → All
Version: 3.6 Branch → Trunk
Severity: major → critical
Keywords: crash
Whiteboard: dupeme
I hit bp-4d1d200f-edf9-45ea-b283-0cebd2120128 in 12.0a1/20120127. The crash signature is a mix of different stacks. Bug 636113 will help breakdown them in different bugs. More reports at: https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char+const*+const%29+|+mozalloc_handle_oom%28unsigned+int%29+|+moz_xrealloc
Status: UNCONFIRMED → NEW
Crash Signature: [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xrealloc]
Component: General → Layout
Depends on: 636113
Ever confirmed: true
Keywords: perfhang
Product: Firefox → Core
QA Contact: general → layout
Summary: crash when opening html file, in which JavaScript has created big amount of tables → OOM crash in nsIFrame::InvalidateInternal when opening html file, in which JavaScript has created big amount of tables
Whiteboard: dupeme
Crash Signature: [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xrealloc] → unsigned int)] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xrealloc] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xrealloc | nsIFrame::InvalidateInternal(nsRect const&, int, int, nsIFra…
Crash Signature: , unsigned int)] → , unsigned int)] [@ mozalloc_abort | mozalloc_handle_oom | moz_xrealloc] [@ mozalloc_abort | mozalloc_handle_oom | moz_xrealloc | nsIFrame::InvalidateInternal]
Closing because no crash reported since 12 weeks.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Reopening because crash bugs **with testcases** should not be resolved **as WONTFIX** based on queries of crash-stats. Other resolutions may be appropriate for other reasons. (Crash signatures are not the same as bug identity; they're merely a search aid to find and group similar crashes. The bug may still be present, but the signature may have changed slightly, or the bug may even still be present with the same signature but there are simply no recent reports of crashes in that function.)
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Severity: critical → S2

The testcase still eventually crashes as an OOM for me; it takes down the content process, which isn't so bad now that we have fission (probably no other sites/tabs will be taken down, if an attacker tries to use this as a DOS vector).

My crash report: bp-9f1264ca-c0f4-49f3-864b-67c8a0221011

Note that my report actually hits OOM in dom code, mozilla::dom::DOMArena::Allocate on behalf of NS_NewHTMLTableSectionElement. So this isn't really a layout-specific OOM; it probably can run out of memory in a somewhat arbitrary spot while we're attempting to load/render the page.

It's also not a Firefox-specific issue; the OOM crash happens in Chrome as well. The testcase eventually results in a Chrome error page:

"Aw, snap! Something went wrong while displaying this webpage. Error code: SIGKILL".

Given the above, I think we can consider this INVALID. Testcases that append large amounts of content in a loop can exhaust browser resources and cause out-of-memory issues, and cause their content process to crash as a result. If this happens in a particularly surprising way (particularly if it's Firefox-specific), then it's bug-worthy; but otherwise it's not really actionable at this point.

Status: REOPENED → RESOLVED
Closed: 6 years ago2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: