This crash happend while trying to reproduce http://code.google.com/p/fbug/issues/detail?id=4613 on a local server in combination with Firebug. Steps to reproduce: 1. Open Firebug on https://getfirebug.com/tests/manual/issues/4613/issue4613.html 2. Enable and switch to the Net panel 3. Choose a big file (~100 MB) to upload 4. Click the "Upload This File" button Related crash report: https://crash-stats.mozilla.com/report/index/bp-536b268c-7d6a-494b-b0cf-249962130408 Sebastian

That's an out-of-memory crash: we attempted to allocate a 200MB+ buffer and failed to do that. Not entirely unlikely, on a 32-bit system with fragmented virtual memory... Based on the description, presumably something is trying to pass a 100e6 char string through xpconnect here? Possibly multiple times, even. The best we can do is to make the relevant allocation fallible and bail out if it fails, but I can't tell based on the stack what the actual allocation site is. That part optimized away or something. :( Can someone reproduce this with a sane 32-bit debug build? Sebastian, is this reliably reproducible? I assume it's not.... Does it become that way if you use a larger file?

> Sebastian, is this reliably reproducible? With the same file as yesterday, no. Thought so yesterday after the second time successfully reproducing the steps. > Does it become that way if you use a larger file? Yes, reliably. See the following crash reports: Though here are some other random crashes related to this: https://crash-stats.mozilla.com/report/index/3b434138-55f7-4c3a-93e8-190402130409 https://crash-stats.mozilla.com/report/index/34d03fd7-a26f-40f1-93be-6037d2130409 https://crash-stats.mozilla.com/report/index/bp-b5cda953-83e2-482e-a485-db5082130409 https://crash-stats.mozilla.com/report/index/55954ae6-f974-4651-90f8-2b2162130409 > Does it become that way if you use a larger file? Trying with a huge file (> 1 GB), yes. Though the crash signature is different: https://crash-stats.mozilla.com/report/index/e7f94642-bc8e-4af2-983e-2d8332130409 https://crash-stats.mozilla.com/report/index/ca47e93d-c198-4ddb-9c1f-9e9ea2130409 https://crash-stats.mozilla.com/report/index/f4cd6df4-46b2-454d-a8b5-dc15e2130409 FWIW, trying with a file with a file size in between (~400 MB) the browser sometimes freezes instead of crashing. When it crashes, the signature is the same as of this report: https://crash-stats.mozilla.com/report/index/ea0116ce-0a94-489f-955f-bc1af2130409 https://crash-stats.mozilla.com/report/index/882f0b6e-1865-47cb-8474-096082130409 Sebastian

Hmm. Those help some: we want to make that SetCapacity fallible. I still can't tell where it's happening, though, what with all the inlining. :(

??? What should I do?

If you have 32-bit Windows debug builds, reproduce the bug and see what the stack looks like? If you don't, then don't worry about it.

I don't see this crash signature but a similar one (see https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char+const*+const%29+|+mozalloc_handle_oom%28unsigned+int%29+|+moz_xmalloc+|+XPC_WN_CallMethod%28JSContext*%2C+unsigned+int%2C+JS%3A%3AValue*%29) in 21.0 and above. Does it happen in Nightly (http://nightly.mozilla.org/)?

I just realized that step 2 is incorrect. It should be: Enable and switch to the Console panel > Does it happen in Nightly (http://nightly.mozilla.org/)? Yes, with a different signature: https://crash-stats.mozilla.com/report/index/bp-d0a77768-9925-40be-9909-0573a2130409 https://crash-stats.mozilla.com/report/index/bp-b7b2c1a5-9b5f-40b2-b90d-22be62130409 Sebastian

With Nightly 37.0a1 (2014-12-15; with disabled e10s to get Firebug working) + Firebug 2.0.7 I can't reproduce that problem anymore. This doesn't guarantee that the bug is really gone as the tested version of Firebug is not the same as the previous one. So should I close this issue, anyway? Sebastian

If it's not really reproducible anymore, I'd resolve worksforme....