Crash in [@ core::option::expect_failed | core::ptr::real_drop_in_place<T> | moz_task::{{impl}}::allocate::Release]
Categories
(Toolkit :: Storage, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox70 | --- | wontfix |
firefox71 | + | fixed |
firefox72 | --- | fixed |
People
(Reporter: marcia, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: crash, regression)
Crash Data
This bug is for crash report bp-174f8d11-4770-4ed3-ab4c-f8ef70191029.
Seen while looking at 70 and 70.0.1 crash stats: https://bit.ly/2CcsTCG. Filing here because I see some KeyValDB in the stack (which traces back to Bug 1490496). This crash is not seen before 70 was in beta, and continued into 70 release.
Some correlations:
(100.0% in signature vs 00.30% overall) moz_crash_reason = drop() called on wrong thread!
(91.44% in signature vs 19.52% overall) Module "duser.dll" = true [100.0% vs 31.99% if platform_version = 6.1.7601 Service Pack 1]
Facebook is called out a few times in the comments.
Top 10 frames of crashing thread:
0 xul.dll GeckoCrash toolkit/xre/nsAppRunner.cpp:5102
1 xul.dll static void gkrust_shared::panic_hook toolkit/library/rust/shared/lib.rs:249
2 xul.dll static void core::ops::function::Fn::call<fn src/libcore/ops/function.rs:69
3 xul.dll static void std::panicking::rust_panic_with_hook src/libstd/panicking.rs:481
4 xul.dll static void std::panicking::continue_panic_fmt src/libstd/panicking.rs:384
5 xul.dll static void std::panicking::rust_begin_panic src/libstd/panicking.rs:311
6 xul.dll static void core::panicking::panic_fmt src/libcore/panicking.rs:85
7 xul.dll void core::option::expect_failed src/libcore/option.rs:1166
8 xul.dll static void core::ptr::real_drop_in_place<kvstore::task::GetOrCreateTask> src/libcore/ptr/mod.rs
9 xul.dll static unsigned int moz_task::{{impl}}::allocate::Release xpcom/rust/moz_task/src/lib.rs:83
Comment 1•3 years ago
|
||
Is there a better component for this? Looks like this might be RKV-related.
Updated•3 years ago
|
Updated•3 years ago
|
Comment 2•3 years ago
|
||
Tracking for 71 given the high crash volume on release.
Too late for 70 at this point with only 2 weeks left before 71 release.
Comment 4•3 years ago
|
||
I believe these are fixed by bug 1596064 or bug 1596065, since this also happens for kvstore, not other consumers of RKV.
New kvstore consumers were introduced in bug 1530996 and bug 1573832. Alex, can you confirm that this crash originates there?
Updated•3 years ago
|
Comment 5•3 years ago
|
||
The stack is not very helpful. I don't see any of the components disabled with Bug 1596064. However, any call to kvstore happens asynchonusly so I would not expect to see much in the stack. In addition to that, the dates on the reports are correct and indicate that it was fixed by Bug 1596064.
I don't expect any crash from Bug 1596065 since it requires the user to press a specific button in about:support, which is used only for debugging.
Comment 6•3 years ago
|
||
(In reply to Victor Porof [:vporof][:vp] from comment #4)
I believe these are fixed by bug 1596064 or bug 1596065, since this also happens for kvstore, not other consumers of RKV.
beta 11 did not have crashes so I am going to mark it fixed for this release.
Comment 7•3 years ago
|
||
No crashes in 71 or 72. Not sure whether this is resolved or just disabled, but doesn't seem to be a worry for the next release at least.
Reporter | ||
Comment 8•3 years ago
|
||
I don't see any crashes in 71 or 72. Can we close this one out?
Comment 9•3 years ago
|
||
Fixed by the above mentioned bugs.
Updated•3 years ago
|
Updated•3 years ago
|
Description
•