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

Status: RESOLVED WORKSFORME

(Firefox :: Sync, defect, P5)

Description

[Andrew McCreight [:mccr8]]

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.

Comment 1

[Lina Butler [:lina]]

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?

Comment 2

[Andrew McCreight [:mccr8]]

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.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit auto_nag documentation.

Comment 4

[Andrew McCreight [:mccr8]]

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.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.