Closed Bug 1593734 Opened 3 years ago Closed 3 years ago

Crash in [@ core::option::expect_failed | core::ptr::real_drop_in_place<T> | moz_task::{{impl}}::allocate::Release]


(Toolkit :: Storage, defect, P1)




Tracking Status
firefox-esr68 --- unaffected
firefox70 --- wontfix
firefox71 + fixed
firefox72 --- fixed


(Reporter: marcia, Unassigned)


(Blocks 1 open bug)


(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: 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/
2 xul.dll static void core::ops::function::Fn::call<fn src/libcore/ops/
3 xul.dll static void std::panicking::rust_panic_with_hook src/libstd/
4 xul.dll static void std::panicking::continue_panic_fmt src/libstd/
5 xul.dll static void std::panicking::rust_begin_panic src/libstd/
6 xul.dll static void core::panicking::panic_fmt src/libcore/
7 xul.dll void core::option::expect_failed src/libcore/
8 xul.dll static void core::ptr::real_drop_in_place<kvstore::task::GetOrCreateTask> src/libcore/ptr/
9 xul.dll static unsigned int moz_task::{{impl}}::allocate::Release xpcom/rust/moz_task/src/

Is there a better component for this? Looks like this might be RKV-related.

Flags: needinfo?(vporof)
Component: General → Storage
Priority: -- → P2

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.

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?

Flags: needinfo?(vporof) → needinfo?(achronop)
Blocks: ship-rkv
Priority: P2 → P1
OS: Windows → Unspecified
Hardware: All → Unspecified
Version: Trunk → unspecified

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.

Flags: needinfo?(achronop)

(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.

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.

I don't see any crashes in 71 or 72. Can we close this one out?

Fixed by the above mentioned bugs.

Closed: 3 years ago
Resolution: --- → FIXED
Blocks: rkv-perf-mode
No longer blocks: ship-rkv
Target Milestone: --- → mozilla72
You need to log in before you can comment on or make changes to this bug.