assertion failed: addresses.windows(2).all(|w| w[0].range.end <= w[1].range.begin) with Android libmozglue.so about addr2line

[philipc]

Couldn't download the file (I've requested access), but I guess we'll need to handle overlapping ranges in a manner similar to #163

[mstange]

Sorry, I've updated the sharing settings (got confused by new UI).

[philipc]

That file contains a lot of functions that are at the same address:

0003c91f T _Unwind_Complete
0003c91f t _ZN15google_breakpad11StackwalkerD2Ev
0003c91f t _ZN15google_breakpad13CFIRuleParser7HandlerD2Ev
0003c91f t _ZN15google_breakpad13ModuleFactoryD2Ev
0003c91f t _ZN15google_breakpad14ExploitabilityD2Ev
0003c91f t _ZN15google_breakpad14MinidumpModule18SetShrinkDownDeltaEy
0003c91f t _ZN15google_breakpad14MinidumpObjectD2Ev
0003c91f t _ZN15google_breakpad22MinidumpUnloadedModule18SetShrinkDownDeltaEy
0003c91f t _ZN17SharedLibraryInfo10InitializeEv
0003c91f t _ZN19MappableExtractFile8finalizeEv
0003c91f t _ZN19ReplaceMallocBridge25DisablePHCOnCurrentThreadEv
0003c91f t _ZN19ReplaceMallocBridge26ReenablePHCOnCurrentThreadEv

etc.

It's fine if I change the assert to this:

        debug_assert!(addresses
            .windows(2)
            .all(|w| w[0].range.end <= w[1].range.begin || w[0].range == w[1].range));

but I think we probably should delete the assert, because it could still trigger for other unlikelier cases. Not sure if we should be trying to handle function ranges that are overlapping but not equal. Can you think of any situation in which that might occur?

[mstange]

Interesting. Thanks for looking into this!

The contents of that function (which for me is at 3c91e rather than 3c91f, for some reason) is just a single instruction: bx lr. According to the internet, this means "Return, and possibly mode switch, depending on the value in the lr register". So it seems like it's basically an empty function. And looking up some of its names in the source, many of them seem to be empty virtual destructors, for example virtual ~MinidumpObject() {}. Since the method is virtual, there needs to be an address for it that can be put in a vtable, so my guess is that this function is just "the empty function" that you can take the address of.

Requiring ranges to be equal if they overlap sounds fine to me, until we see counter-examples. But the bad cases should report an error rather than panicking. Having a library panic on bad input, even if it only happens in debug builds, is quite disruptive.

[philipc]

I'm not sure that we should even return an error for bad cases, since they won't prevent symbolication of the non-overlapping functions. Currently this crate only returns errors for parsing errors, rather than semantic errors too. e.g. if a range has low_pc > high_pc then we ignore it.

[mstange]

Oh I see, that sounds good too. Thanks for the fix!