Closed Bug 1248132 Opened 8 years ago Closed 6 years ago

php code that crashes firefox but not chrome

Categories

(Core :: DOM: HTML Parser, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: usmpadow, Unassigned)

Details

(Keywords: csectype-oom, Whiteboard: [MemShrink:P2])

Crash Data

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36

Steps to reproduce:

at first I thought "how can a server side program crash a client side program?"
on my server, I have a php file with the following code:
<?php for (;;) { echo "<b>MMmm</b><br />\n"; } ?>



Actual results:

firefox froze and crashed and then finally it would start again with the same page, had to quickly close it to avoid the same problem again


Expected results:

well, chrome does not crash, it displays a long list of the 
MMmm
MMmm
MMmm
MMmm
MMmm
MMmm
MMmm
MMmm
MMmm
MMmm
also, sorry I don't give my link, but I don't want to receive many users to my server
OOM from the looks of it. Page janks heavily until eventually exhausting available memory and crashing.
https://crash-stats.mozilla.com/report/index/ffb0cb70-69d7-45b9-8310-00b722160216

Chrome also spikes the CPU and memory use appears to grow indefinitely, albeit at a much slower rate. I strongly suspect that it would also crash if I were patient enough to let it run for long enough.

If someone needs a live example of this testcase, I've uploaded to my personal hosting account. Ping me for the URL.
Group: firefox-core-security → core-security
Status: UNCONFIRMED → NEW
Component: Untriaged → HTML: Parser
Ever confirmed: true
Keywords: csectype-oom
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All
Version: 44 Branch → unspecified
Crash Signature: [@ OOM | large | NS_ABORT_OOM | nsTArray_Impl<T>::AppendElements<T> | nsHtml5TreeBuilder::appendCharacters ]
Group: core-security
If our memory usage is growing much faster than Chrome, this might be interesting to look into as an extreme test case.

But this looks like a safe OOM crash, so it doesn't need to be a security bug.
Whiteboard: [MemShrink]
Weird. I thought I made this fail more gracefully in bug 1029671.
Whiteboard: [MemShrink] → [MemShrink:P2]
Closing because no crash reported since 12 weeks.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: