If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Large Data Submission causes crash: [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | xul.dll@0x126615 ] via js::Shape::set

RESOLVED WORKSFORME

Status

()

Core
General
--
critical
RESOLVED WORKSFORME
6 years ago
5 years ago

People

(Reporter: rtrappman, Unassigned)

Tracking

({crash, dataloss, reproducible})

9 Branch
crash, dataloss, reproducible
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

(Reporter)

Description

6 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
Build ID: 20111220165912

Steps to reproduce:

Submit 500+ Domains to community.opendns.com/domaintagging/submit


Actual results:

The website will process the domains for a while then randomly crashes.


Expected results:

All submissions submitted without crash.
(Reporter)

Updated

6 years ago
Crash Signature: bp-54e156f5-48d6-4217-9e32-8f8492120108 bp-a5942504-7ac4-4d7d-82f1-2d2092120108 bp-8c5c7342-eaed-4f37-a8b6-868422120108
(Reporter)

Updated

6 years ago
(Reporter)

Comment 1

6 years ago
Firefox Crash Reports [@ EMPTY: no crashing thread identified; corrupt dump ] is a "topcrash"
Crash Signature: bp-54e156f5-48d6-4217-9e32-8f8492120108 bp-a5942504-7ac4-4d7d-82f1-2d2092120108 bp-8c5c7342-eaed-4f37-a8b6-868422120108 → [@ EMPTY: no crashing thread identified; corrupt dump ]
Component: Untriaged → General
Depends on: 711568
Keywords: reproducible
OS: Windows 7 → All
Hardware: x86 → All
(Reporter)

Updated

6 years ago
tracking-firefox9: --- → ?
(Reporter)

Comment 2

6 years ago
Finally got Firefox to provide a non null crash signature for this error by putting it in a tab group. This error creates data loss, as no information is recoverable upon crash restart.

Actual Crash Signature: 
[@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | xul.dll@0x126615 ]

Crash ID:
bp-28189b85-6886-445c-a3ce-5036e2120108
Crash Signature: [@ EMPTY: no crashing thread identified; corrupt dump ] → [@ EMPTY: no crashing thread identified; corrupt dump ] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | xul.dll@0x126615 ]
Keywords: common-issue?, dataloss
(Reporter)

Comment 3

6 years ago
Due to the nature of this bug adding priority "critical" like Crash Signature Bug.
Also, I have a feeling that users could get these two crash signatures on any large data submission.
Severity: normal → critical
(Reporter)

Updated

6 years ago
Summary: Large OpenDNS Domain Submissions Crash FireFox → Large Data Submission causes crash: [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | xul.dll@0x126615 ]

Comment 4

6 years ago
The corrupt dump crash signature is for anything, so it must not be taken into account.
With only 78 crashes over the last week, the xul crash signature is not a top crasher.
Status: UNCONFIRMED → NEW
Crash Signature: [@ EMPTY: no crashing thread identified; corrupt dump ] [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | xul.dll@0x126615 ] → [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | xul.dll@0x126615 ]
tracking-firefox9: ? → ---
Depends on: 711973
No longer depends on: 711568
Ever confirmed: true
Keywords: common-issue?

Updated

6 years ago
No longer depends on: 711973

Updated

6 years ago
Depends on: 711973

Updated

6 years ago
Component: General → General
Product: Firefox → Core
QA Contact: untriaged → general
Hmm.  There's not much to go on in that stack... :(

Are we running out of memory while rendering the website, or while submitting the form?  That is, does the server take whatever action is involved before the crash actually happens?
(Reporter)

Comment 6

5 years ago
(In reply to Boris Zbarsky (:bz) from comment #5)
> Hmm.  There's not much to go on in that stack... :(
> 
> Are we running out of memory while rendering the website, or while
> submitting the form?  That is, does the server take whatever action is
> involved before the crash actually happens?

The server processes all submission up until the point in which FireFox would crash.
That doesn't quite answer my question, though....

If you look at the actual HTTP traffic, do we crash before we finish sending (or at least before we get a response from the server)?
(Reporter)

Comment 8

5 years ago
(In reply to Boris Zbarsky (:bz) from comment #7)
> That doesn't quite answer my question, though....
> 
> If you look at the actual HTTP traffic, do we crash before we finish sending
> (or at least before we get a response from the server)?

The connection is still open and trying to actively send data when the crash occurs. Yes, we crash before we finish sending; The server does not respond with the category status (already in category, or new in category) for the domains submitted just before the crash.
OK, thanks.  And this is with no extensions installed, right?  At least the crash reports don't list any...
 rtrappman, does this reproduce with recent nightly build?
Crash Signature: [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | xul.dll@0x126615 ] → [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | xul.dll@0x126615 ] [@ EMPTY: no crashing thread identified; corrupt dump ]
Flags: needinfo?(trappman)
Summary: Large Data Submission causes crash: [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | xul.dll@0x126615 ] → Large Data Submission causes crash: [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | xul.dll@0x126615 ] via js::Shape::set
(Reporter)

Comment 11

5 years ago
(In reply to Wayne Mery (:wsmwk) from comment #10)
>  rtrappman, does this reproduce with recent nightly build?

I have not noticed this issue in the current stable release, I have not tested the nightly though.
Flags: needinfo?(trappman)
WFM per comment 11. Please reopen if you see agina in future.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.