958076 - crash in js::types::ConstraintTypeSet::sweep(JS::Zone*)

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[juan becerra [:juanb]]

This bug was filed from the Socorro interface and is 
report bp-5bcea75e-200b-4e6f-8181-116c02140109.
=============================================================

Reports of with this signature started to appear around January 2, and it is in the top crashers list, top 20. The majority happen in Win7. Fx28 is also affected. There are no comments.

This part of the crashing thread:

Frame 	Module 	Signature 	Source
0 	mozjs.dll 	js::types::ConstraintTypeSet::sweep(JS::Zone *) 	js/src/jsinfer.cpp
1 	mozjs.dll 	js::types::TypeZone::sweep(js::FreeOp *,bool) 	js/src/jsinfer.cpp
2 	mozjs.dll 	JS::Zone::sweep(js::FreeOp *,bool) 	js/src/gc/Zone.cpp
3 	mozjs.dll 	BeginSweepingZoneGroup 	js/src/jsgc.cpp
4 	mozjs.dll 	SweepPhase 	js/src/jsgc.cpp
5 	mozjs.dll 	IncrementalCollectSlice 	js/src/jsgc.cpp
6 	mozjs.dll 	GCCycle 	js/src/jsgc.cpp
7 	mozjs.dll 	Collect 	js/src/jsgc.cpp
8 	mozjs.dll 	js::GCSlice(JSRuntime *,js::JSGCInvocationKind,JS::gcreason::Reason,__int64) 	js/src/jsgc.cpp
9 	mozjs.dll 	JS::IncrementalGC(JSRuntime *,JS::gcreason::Reason,__int64) 	js/src/jsfriendapi.cpp
10 	xul.dll 	nsJSContext::GarbageCollectNow(JS::gcreason::Reason,nsJSContext::IsIncremental,nsJSContext::IsCompartment,nsJSContext::IsShrinking,__int64) 	dom/base/nsJSEnvironment.cpp

Comment 1

[Andrew Truong [:feer56] [:andrewtruong] [:atruong]]

Showed up on sumo: https://support.mozilla.org/en-US/questions/998346

Comment 2

[Robert Kaiser]

Given that frame #1 here is TypeZone:sweep, I wonder if the new 30+ crash at js::types::TypeZone::sweep(js::FreeOp*, bool, bool*) is the same as this here, see 
https://crash-stats.mozilla.com/report/list?signature=js%3A%3Atypes%3A%3ATypeZone%3A%3Asweep%28js%3A%3AFreeOp*%2C%20bool%2C%20bool*%29 for those reports.

Brian, what do you think?

Comment 3

[Brian Hackett [Laid off!]]

Probably, the signature of TypeZone::sweep changed recently so any new crashes should just be morphed versions of existing ones.

Comment 5

[juan becerra [:juanb]]

Carrying over some information from bug 1000996, including which branches are affected.

Comment 6

[u279076]

This is just outside the topcrash range at #11 in Firefox 31, up 8 positions in the last week. Marking this as a topcrash to increase visibility.

Comment 7

[u279076]

This is now one of our top issues in KaiRo's explosivness reports. Raw volume on crashstats still seems outside of topcrash range but the Explosivness report shows this has consistently been below 10 crashes per million ADU until July 2nd where it's increased 10-20x.

Comment 8

[Sylvestre Ledru [:Sylvestre]]

Naveed, anything your team could do to help here? FYI, beta 8 gtb is today.
Thanks

Comment 9

[Wayne Mery (:wsmwk)]

I randomly came across this, having examined 2 users on version 30 who both have a small cluster of different signatures. Just fyi - I'm not saying, and don't know, that this is typical. No bug reports for the signatures that are not js::types::TypeZone::sweep

user 1
https://crash-stats.mozilla.com/report/index/5552da00-9840-40af-a1f6-f7e3e2140714
[@ nsRefPtr<mozilla::dom::Element>::~nsRefPtr<mozilla::dom::Element>() | mozilla::WidgetMouseEvent::`vector deleting destructor''(unsigned int)] - Firefox 30.0 Crash Report - Report ID: 5552da00-9840-40af-a1f6-f7e3e2140714
https://crash-stats.mozilla.com/report/index/b48747e7-db22-4e61-9ede-7df4c2140714
[@ js::gc::IsAboutToBeFinalized<JSObject>] - Firefox 30.0 Crash Report - Report ID: b48747e7-db22-4e61-9ede-7df4c2140714
https://crash-stats.mozilla.com/report/index/5adb7ec0-bdf9-432b-a508-af9ec2140714
[@ js::types::TypeZone::sweep(js::FreeOp*, bool, bool*)] - Firefox 30.0 Crash Report - Report ID: 5adb7ec0-bdf9-432b-a508-af9ec2140714

user 2
https://crash-stats.mozilla.com/report/index/a887c763-f496-4584-8cb8-6bc5e2140711
[@ js::gc::IsAboutToBeFinalized<JSObject>] - Firefox 30.0 Crash Report - Report ID: a887c763-f496-4584-8cb8-6bc5e2140711
https://crash-stats.mozilla.com/report/index/4c755744-b0f0-4d61-a46d-2e1ad2140710
[@ RtlEnterCriticalSection | arena_dalloc | je_free | FinalizeArenas] - Firefox 30.0 Crash Report - Report ID: 4c755744-b0f0-4d61-a46d-2e1ad2140710
https://crash-stats.mozilla.com/report/index/70475f78-9c16-465c-a606-191802140711
[@ js::types::TypeZone::sweep(js::FreeOp*, bool, bool*)] - Firefox 30.0 Crash Report - Report ID: 70475f78-9c16-465c-a606-191802140711

Comment 10

[Robert Kaiser]

The IsAboutToBeFinalized and FinalizeArenas are I believe also GC, just like TypeZone::sweep is, so I'd expect them to be in a pile of GC-related crashes, which can always be related to something else corrupting memory or similar.
The mozilla::WidgetMouseEvent::`vector deleting destructor'' is either a fluke, just something collected in GC, or might be interesting as a place where we go wrong. Is it?

Comment 11

[u279076]

This continues to rise and is currently at #32 (up 12 positions) accounting for 0.37% of our crashes in Firefox 31 over the last week.

Comment 12

[Robert Kaiser]

This is in GC and we backed out GGC from 31, so this probably just means that this GC signature was moved to some other signature with GGC and is back with it disabled. I wouldn't worry about this for 31.

Comment 13

[Sylvestre Ledru [:Sylvestre]]

Too late for 31.

Comment 14

[Terrence Cole [:terrence]]

Some observations:
* Crash addresses are all over the place. This may indication corruption or use of uninitialized memory.
* All stack traces appear to start at incrementalCollectSlice. This is total nonsense -- it's only caller is gcCycle and we never trigger GC from jit-code or via an indirection. This may indicate a corrupt stack, or that we jumped into the GC by accident somehow.

There isn't anything we can do here unless we can get STR.

Comment 15

[Lawrence Mandel [:lmandel] (use needinfo)]

Juan/Kairo - Given comment 14, I'd like us to decide whether this is worth pursuing. How does this crash rate on 32? 

If we need more info including STR, there is an old Sumo link in comment 1 where we may be able to get more information from an affected user.

Comment 16

[juan becerra [:juanb]]

This is at #16 on Fx32 and it is going up. It seems it had a rash of crashes with 8/04, 8/07, and 8/11 builds, so with each the last three betas. We will have to monitor it next week, but it if reaches topcrash territory we need to pursue it.

The comments in the crash reports have very little information to go on, as does the SUMO report. Users mention it just crashes randomly. There are no URLs associated with these reports (I don't know why), and the add-on correlation reports have no information.

I am sending email to one of the users, who had the most information, to see if there is any pattern we can try.

Comment 17

[Robert Kaiser]

(In reply to Lawrence Mandel [:lmandel] from comment #15)
> Juan/Kairo - Given comment 14, I'd like us to decide whether this is worth
> pursuing.

We have seen this around previously in some form, IIRC, and I strongly suspect that it's an unactionable case of GC just stumbling over memory corruption caused elsewhere. If we do not have reproducible cases, I think we unfortunately will need to write it off into that terrain.

Comment 18

[Lawrence Mandel [:lmandel] (use needinfo)]

I'm marking this as won't fix for 32 as we don't have any leads and have very little time left in the beta cycle. I'm tracking for 33. I would like to see us either figure out how to make progress or to write this off as a permanent won't fix unless more information comes in.

Comment 20

[AnAkkk]

Similar crash on ArchLinux, Firefox v33.

#0  0x00007f34c534e379 in raise () from /usr/lib/libpthread.so.0
#1  0x00007f34b6f2c68a in nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*) () from /usr/lib/aurora/libxul.so
#2  <signal handler called>
#3  0x00007f34b762be80 in js::types::TypeScript::Sweep(js::FreeOp*, JSScript*, bool*) () from /usr/lib/aurora/libxul.so
#4  0x00007f34b7629e07 in js::types::TypeZone::sweep(js::FreeOp*, bool, bool*) () from /usr/lib/aurora/libxul.so
#5  0x00007f34b78733ed in JS::Zone::sweep(js::FreeOp*, bool, bool*) () from /usr/lib/aurora/libxul.so
#6  0x00007f34b76195f3 in js::gc::GCRuntime::beginSweepingZoneGroup() () from /usr/lib/aurora/libxul.so
#7  0x00007f34b78a4078 in js::gc::GCRuntime::beginSweepPhase(bool) () from /usr/lib/aurora/libxul.so
#8  0x00007f34b78a3cca in js::gc::GCRuntime::incrementalCollectSlice(long, JS::gcreason::Reason, js::JSGCInvocationKind) () from /usr/lib/aurora/libxul.so
#9  0x00007f34b78a396d in js::gc::GCRuntime::gcCycle(bool, long, js::JSGCInvocationKind, JS::gcreason::Reason) () from /usr/lib/aurora/libxul.so
#10 0x00007f34b78a37a4 in js::gc::GCRuntime::collect(bool, long, js::JSGCInvocationKind, JS::gcreason::Reason) () from /usr/lib/aurora/libxul.so
#11 0x00007f34b6613f98 in nsJSContext::GarbageCollectNow(JS::gcreason::Reason, nsJSContext::IsIncremental, nsJSContext::IsShrinking, long) () from /usr/lib/aurora/libxul.so
#12 0x00007f34b5a83458 in nsTimerImpl::Fire() () from /usr/lib/aurora/libxul.so

Comment 23

[Sylvestre Ledru [:Sylvestre]]

Except if we have a STR, I think this will be tagged as wontfix too for 33.

Comment 24

[Sylvestre Ledru [:Sylvestre]]

Wontfix for 33.

Comment 25

[Wayne Mery (:wsmwk)]

crash activity seems to be mostly gone since version 35.0.1. At the very least, certainly no longer a topcrash.

https://crash-stats.mozilla.com/signature/?signature=js%3A%3Atypes%3A%3AConstraintTypeSet%3A%3Asweep
https://crash-stats.mozilla.com/signature/?signature=js%3A%3Atypes%3A%3ATypeZone%3A%3Asweep
https://crash-stats.mozilla.com/signature/?signature=js%3A%3Atypes%3A%3ATypeObject%3A%3Asweep