Closed Bug 1112741 Opened 10 years ago Closed 4 years ago

Crash in js::ConstraintTypeSet::sweep

Categories

(Core :: JavaScript: GC, defect, P1)

37 Branch
All
macOS
defect

Tracking

()

RESOLVED INVALID
Tracking Status
firefox38 - wontfix
firefox39 --- wontfix
firefox40 --- wontfix
firefox41 --- wontfix
firefox-esr68 --- wontfix
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 --- wontfix
firefox69 --- wontfix
firefox70 --- wontfix
firefox71 --- wontfix
firefox72 --- wontfix

People

(Reporter: automatedtester, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: crash, Whiteboard: [#jsapi:crashes-retriage])

Crash Data

Attachments

(1 file)

This bug was filed from the Socorro interface and is 
report bp-d95a8922-75ad-4651-8293-c8a512141217.
=============================================================
 

Not sure what happened, I ctrl+tab back to it and saw the crash reporter window.
See Also: → 1114850
Happened on Firefox 37.0.1 on Mac: 05125257-f248-43ce-a3ff-f66f32150412
Version: 36 Branch → 37 Branch
This got renamed in 38 by bug 1129226. The new signature is moderately high on the 38 beta crash list. And I found a few oranges that look to be related.

bhackett could you take a look?
Crash Signature: [@ js::types::TypeObject::maybeSweep(js::types::AutoClearTypeInferenceStateOnOOM*)] → [@ js::types::TypeObject::maybeSweep(js::types::AutoClearTypeInferenceStateOnOOM*)] [@ js::ObjectGroup::maybeSweep(js::types::AutoClearTypeInferenceStateOnOOM*) ]
Flags: needinfo?(bhackett1024)
I've looked at this repeatedly.  I don't see anything wrong with the code and can't go any further without some STR.
Flags: needinfo?(bhackett1024)
I doubt I can provide STR, but maybe I can pull some more information out of these dumps.
Flags: needinfo?(dmajor)
I spent a while looking into this but I don't have anything actionable.

Turns out this signature is really a bucket of many different crashes. Our ever-helpful compiler inlined all of |newProp->types.sweep(zone(), *oom)| so any crashes under there get reported as a single line in maybeSweep. Looking at the function offsets, there are a number of different sites where these are happening.

I got lost in the disassembly pretty quickly. I could dive deeper if requested, but any one of these crashes would be individually rather low volume, so it doesn't seem worth the trouble. I wonder if this will just become part of the constant background noise like processMarkStackTop.
Flags: needinfo?(dmajor)
Not tracking as it is not a top crash but I would be happy to take a patch
Crash Signature: [@ js::types::TypeObject::maybeSweep(js::types::AutoClearTypeInferenceStateOnOOM*)] [@ js::ObjectGroup::maybeSweep(js::types::AutoClearTypeInferenceStateOnOOM*) ] → [@ js::types::TypeObject::maybeSweep(js::types::AutoClearTypeInferenceStateOnOOM*)] [@ js::ObjectGroup::maybeSweep(js::types::AutoClearTypeInferenceStateOnOOM*) ] [@ js::ObjectGroup::maybeSweep(js::AutoClearTypeInferenceStateOnOOM*) ]
¡Hola!

What I believe are my steps:

- Open Nightly
- Sleep the laptop
- Plug-in an external VGA monitor
- Wake up the laptop

Result:
about:sessionrestore appears

Report ID 	Date Submitted
bp-233ae61e-e3f3-4b95-bb24-7278a2150617
	17/06/2015	09:49 a.m.

Crashing Thread
Frame 	Module 	Signature 	Source
0 	xul.dll 	js::ObjectGroup::maybeSweep(js::AutoClearTypeInferenceStateOnOOM*) 	js/src/vm/ObjectGroup-inl.h
1 		@0x208f3ccff 	
2 		@0x1a7e3fff 	
3 	xul.dll 	js::jit::DoGetNameFallback 	js/src/jit/BaselineIC.cpp
4 		@0x1339e4969f3
Crash Signature: [@ js::types::TypeObject::maybeSweep(js::types::AutoClearTypeInferenceStateOnOOM*)] [@ js::ObjectGroup::maybeSweep(js::types::AutoClearTypeInferenceStateOnOOM*) ] [@ js::ObjectGroup::maybeSweep(js::AutoClearTypeInferenceStateOnOOM*) ] → [@ js::types::TypeObject::maybeSweep(js::types::AutoClearTypeInferenceStateOnOOM*)] [@ js::ObjectGroup::maybeSweep(js::types::AutoClearTypeInferenceStateOnOOM*) ] [@ js::ObjectGroup::maybeSweep(js::AutoClearTypeInferenceStateOnOOM*) ] [@ js::types::Typ…
guessing that this crash has now moved to the js::ObjectGroup::sweep(js::AutoClearTypeInferenceStateOnOOM*) signature after http://hg.mozilla.org/mozilla-central/rev/a5f31bacc839

on 41 beta this crash is on #12 of the rop crash list btw and resposible for ~1% of all recorded crashes.
Crash Signature: js::types::TypeObject::maybeSweep] [@ js::ObjectGroup::maybeSweep ] → js::types::TypeObject::maybeSweep] [@ js::ObjectGroup::maybeSweep ] [@ js::ObjectGroup::sweep(js::AutoClearTypeInferenceStateOnOOM*) ]
Crash Signature: js::types::TypeObject::maybeSweep] [@ js::ObjectGroup::maybeSweep ] [@ js::ObjectGroup::sweep(js::AutoClearTypeInferenceStateOnOOM*) ] → js::types::TypeObject::maybeSweep] [@ js::ObjectGroup::maybeSweep ] [@ js::ObjectGroup::sweep(js::AutoClearTypeInferenceStateOnOOM*) ] [@ js::ObjectGroup::sweep ]
Many stack traces in js::ConstraintTypeSet::sweep are similar to the ones in js::ObjectGroup::sweep.

I often see the volume of crashes with these signatures go up / down periodically with different Beta builds.

I think at least a subset of the crashes with those signatures are the same.
Crash Signature: js::types::TypeObject::maybeSweep] [@ js::ObjectGroup::maybeSweep ] [@ js::ObjectGroup::sweep(js::AutoClearTypeInferenceStateOnOOM*) ] [@ js::ObjectGroup::sweep ] → js::types::TypeObject::maybeSweep] [@ js::ObjectGroup::maybeSweep ] [@ js::ObjectGroup::sweep(js::AutoClearTypeInferenceStateOnOOM*) ] [@ js::ObjectGroup::sweep ] [@ js::ConstraintTypeSet::sweep ]
Depends on: 1333000
I just got a js::ConstraintTypeSet::sweep crash[1] after letting my machine run over night because of a long-running task. In the meantime it fell in sleep mode. After waking it up again today morning, Firefox has been crashed.
Hope that info helps somehow.

Sebastian

[1] https://crash-stats.mozilla.com/report/index/89f0c058-c815-4eac-86d1-e7faf2170203
The crash is still happening:
https://crash-stats.mozilla.com/report/index/cb6efe79-3fd7-4cf0-91b3-07e9a0170503

In my case it has happened at the time when I did not do any actions (clicks or anything).
Marco, can you please look at the attached screenshot?

Every time I have a crash somehow it wipes out sites' icons, as well as context from all of tabs, even if they are in the background. I have many tabs, and the sites' icons will never reappear unless I manually click on every tab, what is annoying.

Could you please fix SessonStore JSON management in a way so the crashed would not tamper with it? Why, no matter what crash is (I had different signatures with the same effect), tabs lose sites' icons?

Thank you in advance.
Flags: needinfo?(mcastelluccio)
(In reply to User Dderss from comment #18)
> Created attachment 8864095 [details]
> FireFox 53's session gets corrupted after a crash.png
> 
> Marco, can you please look at the attached screenshot?
> 
> Every time I have a crash somehow it wipes out sites' icons, as well as
> context from all of tabs, even if they are in the background. I have many
> tabs, and the sites' icons will never reappear unless I manually click on
> every tab, what is annoying.
> 
> Could you please fix SessonStore JSON management in a way so the crashed
> would not tamper with it? Why, no matter what crash is (I had different
> signatures with the same effect), tabs lose sites' icons?
> 
> Thank you in advance.

Could you file a new bug for this? Since it happens no matter the crash, it's unrelated to this particular bug.
Flags: needinfo?(mcastelluccio)
(In reply to Marco Castelluccio [:marco] from comment #19)
> Could you file a new bug for this? Since it happens no matter the crash,
> it's unrelated to this particular bug.

I can file a new bug, but I do not remember how to file bugs that are not really about specific crashes, but rather broader architecture/mechanics requests such in my case about updating SessionStore JSON management/serialization/synchronization so it would not get corrupted if main FireFox process gets killed due to any crash in principle. Should I use certain tags/keywords/status for such bug?

Also, I now got a new crash (that, of course, yanked the sites' icons, but this is besides the point in this case) https://crash-stats.mozilla.com/report/index/21d7ee78-7af1-45e6-8c30-cd2b31170506 with "@ CCGraphBuilder::BuildGraph" signature that is referenced in #bug 1272230, which is, apparently, meant to be seen/accessed only by Mozilla staff as I only see "You are not authorized to access bug 1272230" error message. Could you please add the link to my crash report to that bug page so your colleagues would look at it?

Thanks in advance, Marco.
Flags: needinfo?(mcastelluccio)
(In reply to User Dderss from comment #20)
> Could you please add the link to my crash report to that bug page so your colleagues would look at it?

There's no need to link that in there. I've looked at a lot of crash reports for it, I'm just not sure how to fix it.
(In reply to User Dderss from comment #20)
> I can file a new bug, but I do not remember how to file bugs that are not
> really about specific crashes, but rather broader architecture/mechanics
> requests such in my case about updating SessionStore JSON
> management/serialization/synchronization so it would not get corrupted if
> main FireFox process gets killed due to any crash in principle. Should I use
> certain tags/keywords/status for such bug?

Just open a bug describing the problem from https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&component=Session%20Restore, don't worry about tags/keywords/status, leave them in their default value.
Flags: needinfo?(mcastelluccio)
Blocks: 1287306
(In reply to Marco Castelluccio [:marco] from comment #22)
> Just open a bug describing the problem from
> https://bugzilla.mozilla.org/enter_bug.
> cgi?product=Firefox&component=Session%20Restore, don't worry about
> tags/keywords/status, leave them in their default value.

Thanks; I filed a separate #bug 1363397 for that.
It seems that none of the crash signatures appeared in the last six months. Should this issue be closed?

Sebastian
Flags: needinfo?(jcoppeard)
(In reply to Sebastian Zartner [:sebo] from comment #24)
Sadly some of them are still happening.  I'll remove the signatures that no longer occur to make this clearer.
Crash Signature: [@ js::types::TypeObject::maybeSweep(js::types::AutoClearTypeInferenceStateOnOOM*)] [@ js::ObjectGroup::maybeSweep(js::types::AutoClearTypeInferenceStateOnOOM*) ] [@ js::ObjectGroup::maybeSweep(js::AutoClearTypeInferenceStateOnOOM*) ] [@ js::types::Typ… → [@ js::ConstraintTypeSet::sweep ] [@ js::ObjectGroup::sweep ] [@ js::ObjectGroup::maybeSweep ] [@ js::types::TypeObject::maybeSweep]
Flags: needinfo?(jcoppeard)
Summary: crash in js::types::TypeObject::maybeSweep(js::types::AutoClearTypeInferenceStateOnOOM*) → Crash in js::ConstraintTypeSet::sweep
No longer blocks: 1425293
Blocks: GCCrashes
Is it back in FF 58.0.2?
Ye(In reply to alexander from comment #26)
> Is it back in FF 58.0.2?

Yes indeed. Here is a crash on 59.1.
There seems to have been a spike around Nightly build 20180519100118. Some crashes are caused by an assertion: "MOZ_RELEASE_ASSERT(uintptr_t(oldArray[-1]) == oldCapacity)".
Crash Signature: [@ js::ConstraintTypeSet::sweep ] [@ js::ObjectGroup::sweep ] [@ js::ObjectGroup::maybeSweep ] [@ js::types::TypeObject::maybeSweep] → [@ js::ConstraintTypeSet::sweep ] [@ js::ObjectGroup::sweep ] [@ js::ObjectGroup::maybeSweep ] [@ js::types::TypeObject::maybeSweep] [@ JSScript::sweepTypes]
Whiteboard: [#jsapi:crashes-retriage]
Firefox 62.0a [@ js::ObjectGroup::sweep ] assertion in bp-b9e225e3-6076-4ba2-8ea5-7c6130180623 :
MOZ_CRASH Reason:  MOZ_RELEASE_ASSERT(!propertySet)
See Also: → 1472632
Keywords: stalled
Priority: -- → P1

https://bit.ly/2XlpACq - this signature appears more visible in 67 nightly in the last 7 days - 75 crashes/66 installations and is #20 top crash overall. No comments and not much to go on the URLs:

Correlations:
(100.0% in signature vs 37.73% overall) is_garbage_collecting = null
(80.70% in signature vs 21.66% overall) reason = EXCEPTION_BREAKPOINT
(100.0% in signature vs 68.65% overall) gmp_plugin = null [28.30% vs 68.64% if process_type = content]
(19.30% in signature vs 56.98% overall) address = 0x0
(29.82% in signature vs 69.03% overall) ipc_message_name = null
(63.16% in signature vs 99.28% overall) plugin_filename = null
(33.33% in signature vs 68.53% overall) plugin_name = null
(24.56% in signature vs 07.37% overall) Module "atl.dll" = true [30.43% vs 08.44% if platform = Windows NT]
(21.05% in signature vs 05.29% overall) Module "msmpeg2adec.dll" = true [26.09% vs 06.06% if platform = Windows NT]
(19.30% in signature vs 03.66% overall) Module "igd10umd64.dll" = true
(33.33% in signature vs 69.07% overall) theme = null [83.33% vs 100.0% if startup_crash = null]
(100.0% in signature vs 30.90% overall) ipc_message_name = null ∧ ipc_system_error = null
(100.0% in signature vs 36.16% overall) ipc_message_name = null ∧ abort_message = null
(29.82% in signature vs 98.46% overall) ipc_channel_error = null ∧ e10s_enabled = 1
(29.82% in signature vs 98.25% overall) plugin_version = null ∧ e10s_enabled = 1
(33.33% in signature vs 99.38% overall) ipc_channel_error = null ∧ release_channel = nightly
(31.58% in signature vs 97.08% overall) Addon "screenshots@mozilla.org" Version = 37.1.0 ∧ graphics_startup_test = null
(33.33% in signature vs 97.35% overall) jit_category = null ∧ Addon "webcompat@mozilla.org" Version = 3.0.0
(35.09% in signature vs 97.35% overall) Addon "webcompat@mozilla.org" Version = 3.0.0 ∧ ipc_fatal_error_protocol = null
(35.09% in signature vs 96.65% overall) Addon "webcompat@mozilla.org" Version = 3.0.0 ∧ plugin_filename = null
(33.33% in signature vs 93.65% overall) "WR?" in app_notes = true ∧ is_garbage_collecting = null
(35.09% in signature vs 93.65% overall) "WR?" in app_notes = true ∧ gmp_plugin = null
(31.58% in signature vs 74.40% overall) is_garbage_collecting = null ∧ process_type = content
(100.0% in signature vs 68.90% overall) ipc_message_name = null ∧ ipc_fatal_error_msg = null
(29.82% in signature vs 69.07% overall) is_garbage_collecting = null ∧ graphics_startup_test = null
(29.82% in signature vs 68.52% overall) jit_category = null ∧ safe_mode = 0
(68.42% in signature vs 30.16% overall) Addon "webcompat@mozilla.org" Version = 3.0.0 ∧ is_garbage_collecting = null

Crash Signature: [@ js::ConstraintTypeSet::sweep ] [@ js::ObjectGroup::sweep ] [@ js::ObjectGroup::maybeSweep ] [@ js::types::TypeObject::maybeSweep] [@ JSScript::sweepTypes] → [@ js::ConstraintTypeSet::sweep ] [@ js::ObjectGroup::sweep ] [@ js::ObjectGroup::maybeSweep ] [@ js::types::TypeObject::maybeSweep] [@ JSScript::sweepTypes] [@ js::ConstraintTypeSet::sweep(const class js::AutoSweepBase & const, class JS::Zone *)]
Crash Signature: [@ js::ConstraintTypeSet::sweep ] [@ js::ObjectGroup::sweep ] [@ js::ObjectGroup::maybeSweep ] [@ js::types::TypeObject::maybeSweep] [@ JSScript::sweepTypes] [@ js::ConstraintTypeSet::sweep(const class js::AutoSweepBase & const, class JS::Zone *)] → [@ js::ConstraintTypeSet::sweep ] [@ js::ObjectGroup::sweep ] [@ js::ObjectGroup::maybeSweep ] [@ js::types::TypeObject::maybeSweep] [@ JSScript::sweepTypes] [@ js::ConstraintTypeSet::sweep(const class js::AutoSweepBase & const, class JS::Zone *)]
Crash Signature: [@ js::ConstraintTypeSet::sweep ] [@ js::ObjectGroup::sweep ] [@ js::ObjectGroup::maybeSweep ] [@ js::types::TypeObject::maybeSweep] [@ JSScript::sweepTypes] [@ js::ConstraintTypeSet::sweep(const class js::AutoSweepBase & const, class JS::Zone *)] → [@ js::ConstraintTypeSet::sweep ] [@ js::ObjectGroup::sweep ]
Crash Signature: [@ js::ConstraintTypeSet::sweep ] [@ js::ObjectGroup::sweep ] → [@ js::ConstraintTypeSet::sweep ] [@ js::ObjectGroup::sweep ] [@ `anonymous namespace'::TypeCompilerConstraint<T>::sweep]

This code no longer exists (disabled with Warp in 83 then removed in bug 1673553).

Status: NEW → RESOLVED
Crash Signature: [@ js::ConstraintTypeSet::sweep ] [@ js::ObjectGroup::sweep ] [@ `anonymous namespace'::TypeCompilerConstraint<T>::sweep] → [@ js::ConstraintTypeSet::sweep ] [@ js::ObjectGroup::sweep ] [@ `anonymous namespace'::TypeCompilerConstraint<T>::sweep]
Closed: 4 years ago
Resolution: --- → INVALID

Since the bug is closed, the stalled keyword is now meaningless.
For more information, please visit auto_nag documentation.

Keywords: stalled
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: