Closed Bug 1639996 Opened 2 years ago Closed 2 years ago

Crash in [@ OOM | large | mozalloc_abort | <name omitted> | <dogear::tree::Tree as core::convert::TryFrom<dogear::tree::Builder>>::try_from ]

Categories

(Firefox :: Sync, defect, P5)

defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mccr8, Unassigned)

References

Details

(Keywords: crash)

Crash Data

This bug is for crash report bp-34da10d4-80ac-4142-862f-76b0a0200520.

Top 10 frames of crashing thread:

0 libmozglue.dylib mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:33
1 libmozglue.dylib <name omitted> memory/mozalloc/mozalloc_oom.cpp:51
2 XUL gkrust_shared::oom_hook::hook toolkit/library/rust/shared/lib.rs:221
3 XUL rust_oom src/libstd/alloc.rs:240
4 XUL alloc::alloc::handle_alloc_error src/liballoc/alloc.rs:268
5 XUL <dogear::tree::Tree as core::convert::TryFrom<dogear::tree::Builder>>::try_from third_party/rust/dogear/src/tree.rs
6 XUL <bookmark_sync::store::Store as dogear::store::Store>::fetch_remote_tree toolkit/components/places/bookmark_sync/src/store.rs:440
7 XUL bookmark_sync::merger::MergeTask::merge third_party/rust/dogear/src/store.rs:75
8 XUL <bookmark_sync::merger::MergeTask as moz_task::Task>::run toolkit/components/places/bookmark_sync/src/merger.rs:217
9 XUL moz_task::TaskRunnable::allocate::Run xpcom/rust/moz_task/src/lib.rs:132

There's only a single instance of this crash, which has Rust Sync code in the stack, but it might be worth looking at, because the OOM allocation size is 16,565,899,576,099,806,975 bytes, which suggests that something has gone terribly wrong.

Ooooh, fascinating! That looks suspiciously close to 2^64—give or take two quintillion! 😅 Integer overflow of some kind? The only other thing that stands out is possible recursion when resolving parents (but this doesn't look like a stack overflow) or our use of a SmallBitVec (like, has something gone wrong spilling it onto the heap?), but those are totally uneducated guesses. What's the next step in investigating something like this?

Yeah, it is probably some kind of integer underflow. Like if there's an empty array, and somebody tries to remove something from it without checking that it is empty, then the new size of the array will be really huge. I'm not sure what the best way to investigate it is. There don't seem to be very good line numbers here. I'd look for places that do subtraction, or remove things from an indexed container.

See Also: → 1640942
Priority: -- → P5

The severity field is not set for this bug.
:markh, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(markh)

Thanks to bug 1640942, this crash now has a more specific signature. I reprocessed the crash in comment 0, and ended up with this one.

Crash Signature: [@ OOM | large | mozalloc_abort | <name omitted> | gkrust_shared::oom_hook::hook | rust_oom] → [@ OOM | large | mozalloc_abort | <name omitted> | <dogear::tree::Tree as core::convert::TryFrom<dogear::tree::Builder>>::try_from ]
Summary: Crash in [@ OOM | large | mozalloc_abort | <name omitted> | gkrust_shared::oom_hook::hook | rust_oom] → Crash in [@ OOM | large | mozalloc_abort | <name omitted> | <dogear::tree::Tree as core::convert::TryFrom<dogear::tree::Builder>>::try_from ]
Flags: needinfo?(markh)
Severity: -- → S3

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.