859247 - crash in nsACString_internal::SetCapacity with abort message: "OOM: file e:\builds\...\xpcom\string\src\nsTSubstring.cpp, line 533"

Status: RESOLVED WORKSFORME

(Core :: XPConnect, defect)

Description

[Sebastian Zartner [:sebo]]

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

Comment 1

[Boris Zbarsky [:bzbarsky]]

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?

Comment 2

[Sebastian Zartner [:sebo]]

> 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

Comment 3

[Boris Zbarsky [:bzbarsky]]

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.  :(

Comment 4

[Alice0775 White]

??? What should I do?

Comment 5

[Boris Zbarsky [:bzbarsky]]

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.

Comment 6

[Scoobidiver (away)]

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/)?

Comment 7

[Sebastian Zartner [:sebo]]

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

Comment 8

[Sebastian Zartner [:sebo]]

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

Comment 9

[Boris Zbarsky [:bzbarsky]]

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