Closed
Bug 1144063
Opened 10 years ago
Closed 7 years ago
crashfirefox.com makes the browser very slow or makes it crash
Categories
(Core :: Networking, defect, P3)
Core
Networking
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
Updated•10 years ago
|
Crash Signature: mozalloc_abort(char const*) | NS_DebugBreak | mozilla::ipc::MessageChannel::OnChannelErrorFromLink()
Updated•10 years ago
|
OS: Linux → All
Hardware: x86_64 → All
Comment 1•10 years ago
|
||
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
Updated•10 years ago
|
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Comment 3•10 years ago
|
||
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 → ---
Comment 4•10 years ago
|
||
Valentin, May I ask you to take a look at this, you were fixing url stuff. :) Thanks.
Flags: needinfo?(dd.mozilla) → needinfo?(valentin.gosu)
Assignee | ||
Comment 5•10 years ago
|
||
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)
Comment 6•10 years ago
|
||
> 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 | ||
Updated•10 years ago
|
Assignee: nobody → valentin.gosu
Assignee | ||
Comment 7•10 years ago
|
||
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.
Comment 8•10 years ago
|
||
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.
Comment 10•10 years ago
|
||
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.
Comment 11•10 years ago
|
||
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>?
Comment 12•10 years ago
|
||
I don't see what this has to do with the awesomebar per se.
Comment 13•9 years ago
|
||
Reported on Webcompat.com today
https://webcompat.com/issues/1978
Updated•9 years ago
|
Whiteboard: [necko-backlog]
Comment 15•7 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Comment 16•7 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
Assignee | ||
Comment 17•7 years ago
|
||
This bug doesn't crash Firefox anymore due to "Navigation to toplevel data: URI not allowed"
Status: REOPENED → RESOLVED
Closed: 10 years ago → 7 years ago
Resolution: --- → WORKSFORME
Comment 18•7 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•