Closed Bug 1144063 Opened 10 years ago Closed 6 years ago

crashfirefox.com makes the browser very slow or makes it crash

Categories

(Core :: Networking, defect, P3)

defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: bbouvier, Assigned: valentin)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-backlog])

Crash Data

So this has been reported from a French website [0] which is pretty popular. Basically, there is this website http://crashfirefox.com, which redirects you to the following encoded URL:

    data:text/html,<script>location+=location+'A'.repeat(100000000);</script>

And that makes Firefox very slow, if not crashy. For instance, I could have a crash with e10s:

https://crash-stats.mozilla.com/report/index/6ff721d5-8bcd-4e72-b25e-e085c2150317

Note that if you have this piece of code in a <script> balise of a page (and not in the data URL), the browser doesn't crash, instead it will show this in the console:

    NS_ERROR_MALFORMED_URI: 

I don't really know which component is in fault here, but I suspect window.location somehow, or just the data URI component which should also show the NS_ERROR. Trying Core::DOM... 

[0] http://korben.info/planter-firefox-en-1-click.html
Crash Signature: mozalloc_abort(char const*) | NS_DebugBreak | mozilla::ipc::MessageChannel::OnChannelErrorFromLink()
OS: Linux → All
Hardware: x86_64 → All
Presumably the issue is just that it's a huge data: URI and we OOM on it, no?

The e10s crash linked is in e10s specific code that decides it wants to kill off the process for reasons that are not clear to me.
Component: DOM → Networking
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Dragana, I've seen this crash / hang with the latest nightly (I've just restarted it to ensure it's the latest), which should contain the fix in bug 1135354 (landed 03/11). But the crash still happens!

See an example of crash in latest nightly:
https://crash-stats.mozilla.com/report/index/881ce179-8ca2-42dc-a21c-aa8e52150317
Status: RESOLVED → REOPENED
Flags: needinfo?(dd.mozilla)
Resolution: DUPLICATE → ---
Valentin, May I ask you to take a look at this, you were fixing url stuff. :) Thanks.
Flags: needinfo?(dd.mozilla) → needinfo?(valentin.gosu)
Actually, bug 1135354 does not fix this.
The URI here, data:text/html,<script>location+=location+'A'.repeat(100000000);</script> is under 100 chars long, so the there's no early return for this one.

From what I can tell, the problem here is that we're trying to allocate a huge string, even before we build a URI. Boris, is there a way we can set a max limit on a string? And is that something we should do?

const&, nsID const*, nsresult*) () from /home/icecold/.apps/firefox/libxul.so
#13 0x00007fc04b3ffa96 in XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) () from /home/icecold/.apps/firefox/libxul.so
#14 0x00007fc04b402276 in XPC_WN_GetterSetter(JSContext*, unsigned int, JS::Value*) () from /home/icecold/.apps/firefox/libxul.so
#15 0x00007fc04b5b2f1d in js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) () from /home/icecold/.apps/firefox/libxul.so
#16 0x00007fc04b5b3994 in js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) () from /home/icecold/.apps/firefox/libxul.so
#17 0x00007fc04b5b3bb4 in js::InvokeGetterOrSetter(JSContext*, JSObject*, JS::Value, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) () from /home/icecold/.apps/firefox/libxul.so
#18 0x00007fc04b5c7506 in js::NativeGetProperty(JSContext*, JS::Handle<js::NativeObject*>, JS::Handle<JSObject*>, JS::Handle<jsid>, JS::MutableHandle<JS::Value>) ()
   from /home/icecold/.apps/firefox/libxul.so
#19 0x00007fc04b55401e in js::GetProperty(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, JS::Handle<jsid>, JS::MutableHandle<JS::Value>) () from /home/icecold/.apps/firefox/libxul.so
#20 0x00007fc04b5a54aa in Interpret(JSContext*, js::RunState&) () from /home/icecold/.apps/firefox/libxul.so
#21 0x00007fc04b5b2a71 in js::RunScript(JSContext*, js::RunState&) () from /home/icecold/.apps/firefox/libxul.so
#22 0x00007fc04b5b3000 in js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) () from /home/icecold/.apps/firefox/libxul.so
#23 0x00007fc04b66a41e in js::fun_apply(JSContext*, unsigned int, JS::Value*) () from /home/icecold/.apps/firefox/libxul.so
#24 0x00007fc04b5b2f1d in js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) () from /home/icecold/.apps/firefox/libxul.so
#25 0x00007fc04b5b3994 in js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) () from /home/icecold/.apps/firefox/libxul.so
#26 0x00007fc04b61ffec in js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICCall_Fallback*, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) ()
   from /home/icecold/.apps/firefox/libxul.so
Flags: needinfo?(valentin.gosu) → needinfo?(bzbarsky)
> The URI here, data:text/html,<script>location+=location+'A'.repeat(100000000);</script>
> is under 100 chars long

Yes, but it sets location to a URL that's 1e8 chars long.

> the problem here is that we're trying to allocate a huge string, even before we build a
> URI

That shouldn't be a problem per se, as long as the relevant consumers use the fallible string methods and throw as needed on failure.

> And is that something we should do?

Imo, no.
Flags: needinfo?(bzbarsky)
Assignee: nobody → valentin.gosu
Right, the problem here isn't the actual strings, but the fact that it goes into a loop of appending to the URI and executing the script.
This URI does the same thing basically, only a bit slower:
data:text/html,<script>location+=location+'A'</script>

I'll try to add a size limit to nsLocation as well.
Adding a random size limit seems pretty odd to me.  We should be handling the OOM as needed, no?
If you visit the page in Chrome the tab crashes after a short while whith "Either Chrome ran out of memory or the process for the webpage was terminated for some other reason". So it seems Chrome is handling the OOM. Seems like a better way than to add a size limit.
This ended up crashing the tab process with e10s on Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:40.0) Gecko/20100101 Firefox/40.0 ID:20150415030206 CSet: a6f7a33731bc , but the signature is a bit different.

Report ID 	Date Submitted
bp-42319cff-f90e-4188-aa4f-8e6e02150415
	15/04/2015	12:46 p.m.
Tried again and got yet another signature.

Report ID 	Date Submitted
bp-3405d66f-e0d9-46e5-9892-0cbf22150419
	19/04/2015	12:23 p.m.

Shall I file separate bugs from these crashes?

Does the awesome bar have to allow <script>?
I don't see what this has to do with the awesomebar per se.
Reported on Webcompat.com today
https://webcompat.com/issues/1978
Whiteboard: [necko-backlog]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
Blocks: 1416078
This bug doesn't crash Firefox anymore due to "Navigation to toplevel data: URI not allowed"
Status: REOPENED → RESOLVED
Closed: 10 years ago6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.