OOM crash in nsIFrame::InvalidateInternal when opening html file, in which JavaScript has created big amount of tables
Categories
(Core :: Layout, defect)
Tracking
()
People
(Reporter: z.dolezal, Unassigned)
References
Details
(Keywords: crash, hang, testcase)
Crash Data
Attachments
(1 file)
573 bytes,
text/html
|
Details |
Comment 3•14 years ago
|
||
Comment 5•14 years ago
|
||
Comment 7•14 years ago
|
||
Updated•14 years ago
|
Comment 8•14 years ago
|
||
Comment 9•13 years ago
|
||
Updated•13 years ago
|
Comment 10•13 years ago
|
||
Updated•13 years ago
|
Updated•9 years ago
|
Comment 11•6 years ago
|
||
Updated•2 years ago
|
Comment 13•2 years ago
•
|
||
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.
Description
•