743221 - Firefox crash @ js::types::HashSetInsertTry<int, js::types::Property, js::types::Property> and perhaps [@ EMPTY: no crashing thread identified; corrupt dump ]

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Wayne Mery (:wsmwk)]

Attachment: windbg stacktrace

+++ This bug was initially created as a clone of Bug #711568 +++

this signature accounts for 50% of my crashes, both at home (vista) and at work (64bit win7).
nightly builds in both places

Still trying to figure it out.
almost always, I am not present at the computer.
and, firefox memory usage was not high when I left the computer.

bp-24f5dceb-730e-4ab6-b64c-8a18f2120405 is an example

my most recent attempt at capturing something with wndbg is attached.
 Use !analyze -v to get detailed debugging information.
 Event is not an exception

I attempted -v hang  but got nothing.
Will try again.


Other crash sigs from this year are these three (one crash each):
js::gc::MarkChildren  bp-10beb796-4024-41e0-b785-1dc062120315
js_GetIndexFromBytecode  bp-2a54579b-171f-474e-9492-141422120128
jvm.dll@0x5e4e2  bp-dd4eabcf-f0e1-4e7b-8646-eb8562120106

Comment 1

[Wayne Mery (:wsmwk)]

> this signature accounts for 50% of my crashes, both at home (vista) and at
> work (64bit win7).
> nightly builds in both places

apparently my memory stinks - work crashes are not EMPTY, and no crash at work in 3 months.

Comment 2

[Wayne Mery (:wsmwk)]

Attachment: windbg stacktrace 2012-04-08 !analyze -f and -v

I also have a minidump. 1.6MB
Firefox 14.0a1 20120324


SYMBOL_STACK_INDEX:  0
SYMBOL_NAME:  mozjs!js::types::HashSetInsertTry<int,js::types::Property,js::types::Property>+8b
MODULE_NAME: mozjs
IMAGE_NAME:  mozjs.dll
DEBUG_FLR_IMAGE_TIMESTAMP:  4f6db70f
STACK_COMMAND:  ~0s ; kb
FAILURE_BUCKET_ID:  INVALID_POINTER_READ_c0000005_mozjs.dll!js::types::HashSetInsertTry_int,js::types::Property,js::types::Property_
BUCKET_ID:  APPLICATION_FAULT_INVALID_POINTER_READ_mozjs!js::types::HashSetInsertTry_int,js::types::Property,js::types::Property_+8b

Comment 3

[Wayne Mery (:wsmwk)]

(In reply to Wayne Mery (:wsmwk) from comment #0)
> Other crash sigs from this year are these three (one crash each):
> js::gc::MarkChildren  bp-10beb796-4024-41e0-b785-1dc062120315
> js_GetIndexFromBytecode  bp-2a54579b-171f-474e-9492-141422120128
> jvm.dll@0x5e4e2  bp-dd4eabcf-f0e1-4e7b-8646-eb8562120106

For the record, I have 21 crash reports/IDs this year on this home laptop, plus comment 2.
Three are the above signatures.
Three were throttled and not submitted.
Plus 
- mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xmalloc | nsStreamLoader::OnStartRequest(nsIRequest*, nsISupports*)
- nsINode::OwnerDoc() (which is perhaps fixed)

The remaining 13 are "EMPTY".  

Is comment 2 crash js::types::HashSetInsertTry<int,js::types::Property,js::types::Property> ?

Comment 4

[Scoobidiver (away)]

More reports at:
https://crash-stats.mozilla.com/report/list?signature=js%3A%3Atypes%3A%3AHashSetInsertTry%3Cint%2C+js%3A%3Atypes%3A%3AProperty%2C+js%3A%3Atypes%3A%3AProperty%3E

Comment 5

[Wayne Mery (:wsmwk)]

This bug is explicitly about sorting out my [@ EMPTY: no crashing thread identified; corrupt dump ].  If a crash in a comment turns out to be completely unrelated (which we might not know yet), let's file a new bug.

Comment 6

[Scoobidiver (away)]

There's a spike in crashes in 15.0a1/20120519. The regression range for the spike is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e794cef56df6&tochange=642d1a36702f

More reports at:
https://crash-stats.mozilla.com/report/list?signature=js%3A%3Atypes%3A%3AHashSetInsertTry%3Cint%2C+js%3A%3Atypes%3A%3AProperty%2C+js%3A%3Atypes%3A%3AProperty%3E

Comment 7

[bogas04]

https://crash-stats.mozilla.com/report/index/bp-b6a7190e-4a1f-4cca-8243-4a85a2120520

Occurred when I deleted all profiles and started afresh with Nightly and started syncing. 1gb+ leak / total 2gb ram. 

This bug is maybe a duplicate of Bug 711568

Comment 8

[Scoobidiver (away)]

(In reply to bogas04 from comment #7)
> https://crash-stats.mozilla.com/report/index/bp-b6a7190e-4a1f-4cca-8243-
> 4a85a2120520
> This bug is maybe a duplicate of Bug 711568
The spike in comment 6 is about the js::types::HashSetInsertTry crash signature, not the empty crash signature.

Comment 9

[Robert Kaiser]

(In reply to Scoobidiver from comment #6)
> There's a spike in crashes in 15.0a1/20120519.

We had at least one change in this build that caused a range of crashes, maybe that spike is connected to the same. Let's see if it stays high when the fix to bug 756851 goes out in tomorrow's Nightly.

Comment 10

[Scoobidiver (away)]

The spike is gone because of http://hg.mozilla.org/mozilla-central/rev/fb3036d9b9e6.

Comment 11

[Wayne Mery (:wsmwk)]

I crashed again bp-a88f9027-6c21-45c5-9030-473432120528 - presumably not because of regression bug 755604

perhaps not a coincidence, earlier in the evening I had used the readability addon via http://www.readability.com/articles/q3svaz75 -- xref bug 756261

Comment 12

[Merike Sell (:merike)]

https://crash-stats.mozilla.com/report/index/89091a93-27af-45ef-88a7-afc722140117

Comment 13

[Wayne Mery (:wsmwk)]

I no longer see this type of crash. But, I also no longer have tab counts in the multiple hundreds because Fx isn't performant any more at that level.  So leaving this open

Comment 14

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

I'm marking this bug as WORKSFORME as bug crashlog signature didn't appear from a long time (over half year) in Firefox (except some obsolete Fx <38, no crashes starting since Fx 38).