Crash in js::ConstraintTypeSet::sweep
Categories
(Core :: JavaScript: GC, defect, P1)
Tracking
()
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)
113.54 KB,
image/png
|
Details |
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.
Comment 1•10 years ago
|
||
Happened on Firefox 37.0.1 on Mac: 05125257-f248-43ce-a3ff-f66f32150412
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?
Comment 4•10 years ago
|
||
I've looked at this repeatedly. I don't see anything wrong with the code and can't go any further without some STR.
I doubt I can provide STR, but maybe I can pull some more information out of these dumps.
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.
Comment 8•9 years ago
|
||
¡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
Updated•9 years ago
|
Comment 9•9 years ago
|
||
Still happening in the latest version, 40.0.3: https://crash-stats.mozilla.com/report/index/2721ed85-ac83-4ddd-b5d9-366372150904#frames
Comment 10•9 years ago
|
||
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.
Updated•9 years ago
|
Comment 11•9 years ago
|
||
This defect is still a serious problem in v46.0a1. https://crash-stats.mozilla.com/report/list?product=Firefox&signature=js%3A%3AObjectGroup%3A%3Asweep#tab-reports It isn't going away.
Comment 12•9 years ago
|
||
(In reply to Common User Network Terminal from comment #11) > This defect is still a serious problem in v46.0a1. And v47.0a1, e.g.: https://crash-stats.mozilla.com/report/index/2641e067-d2dd-4f4b-8588-0d3762160303 "Keeps crashing, freezing the browser & my PC. Why??" https://crash-stats.mozilla.com/report/index/16dbda5d-db36-4f42-bb4b-5c8bb2160303 https://crash-stats.mozilla.com/report/index/e690c639-fa06-43b4-a774-5e4672160303 https://crash-stats.mozilla.com/report/index/642da339-51fe-477d-85d1-f6a7a2160306 https://crash-stats.mozilla.com/report/index/801700dc-4f73-4d81-b02f-3f42b2160307 https://crash-stats.mozilla.com/report/index/b8481be8-706c-485e-a556-b451a2160308 https://crash-stats.mozilla.com/report/index/22710fc0-5d8c-4df5-b6ba-3ca132160308 https://crash-stats.mozilla.com/report/index/22710fc0-5d8c-4df5-b6ba-3ca132160308 https://crash-stats.mozilla.com/report/index/646c0c46-4f78-4899-b89b-947e02160307 https://crash-stats.mozilla.com/report/index/e1d1ed27-d885-4c07-b71e-88d0c2160304 https://crash-stats.mozilla.com/report/index/76e87219-4fb7-4145-bf8f-5e33d2160305 https://crash-stats.mozilla.com/report/index/1ba0de49-8bb2-474c-b100-007d42160303 https://crash-stats.mozilla.com/report/index/94884422-a99b-469c-8cba-799902160304 https://crash-stats.mozilla.com/report/index/29361144-a849-4749-84a5-43d122160306 ..etc > It isn't going away.
Comment 15•8 years ago
|
||
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.
Comment 16•8 years ago
|
||
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
Comment 17•8 years ago
|
||
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).
Comment 18•8 years ago
|
||
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.
Comment 19•8 years ago
|
||
(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.
Comment 20•8 years ago
|
||
(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.
Comment 21•8 years ago
|
||
(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.
Comment 22•8 years ago
|
||
(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.
Comment 23•7 years ago
|
||
(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.
Comment 24•7 years ago
|
||
It seems that none of the crash signatures appeared in the last six months. Should this issue be closed? Sebastian
Comment 25•7 years ago
|
||
(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.
Comment 26•7 years ago
|
||
Is it back in FF 58.0.2?
Comment 27•7 years ago
|
||
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.
Comment 28•6 years ago
|
||
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)".
Updated•6 years ago
|
Updated•6 years ago
|
Comment 29•6 years ago
|
||
Firefox 62.0a [@ js::ObjectGroup::sweep ] assertion in bp-b9e225e3-6076-4ba2-8ea5-7c6130180623 : MOZ_CRASH Reason: MOZ_RELEASE_ASSERT(!propertySet)
Updated•6 years ago
|
Comment 31•6 years ago
|
||
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:
- https://www.bitmex.com/app/trade/XBTUSD
- netflix
- https://www.twitch.tv/
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
Comment 32•6 years ago
|
||
¡Hola!
https://crash-stats.mozilla.com/signature/?product=Firefox&signature=js%3A%3AReportMagicWordFailure&date=%3E%3D2018-12-30T13%3A50%3A00.000Z&date=%3C2019-03-30T13%3A50%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-version&_sort=-date&page=1 has plenty of 68s so I'm updating the flag.
¡Gracias!
Alex
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 36•4 years ago
|
||
This code no longer exists (disabled with Warp in 83 then removed in bug 1673553).
Comment 37•4 years ago
|
||
Since the bug is closed, the stalled keyword is now meaningless.
For more information, please visit auto_nag documentation.
Updated•3 years ago
|
Description
•