Recent Firefox "XUL" binaries encounter MissingUnitDie

[mstange]

Steps to reproduce:

wget https://symbols.mozilla.org/XUL/3378E7F8C8E339A6AAAD847F4A12748D0/XUL.dSYM.tar.bz2
tar -xvf XUL.dSYM.tar.bz2
git clone https://github.com/gimli-rs/addr2line
cd addr2line
cargo run --example addr2line -- -i -f -e ../XUL.dSYM/Contents/Resources/DWARF/XUL 14c601b

Expected results:
A call stack

Actual results:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: MissingUnitDie', src/libcore/result.rs:999:5

I was trying to obtain the inline call stack for module offset 0x14c601b for the "XUL" binary from a recent Firefox macOS nightly build. It's possible that something in the pipeline produced invalid dwarf information, but maybe it makes sense to handle this particular case more gracefully.

[mstange]

This is encountered in Unit<R>::new_internal when calling cursor.current() directly after the initial cursor.next_dfs()?; call.

offset is DebugInfoOffset(DebugInfoOffset(1734277)) and header is UnitHeader { encoding: Encoding { format: Dwarf32, version: 2, address_size: 8 }, unit_length: 7, debug_abbrev_offset: DebugAbbrevOffset(0), entries_buf: EndianReader { range: SubRange { bytes: [51, 0, 0, 0, 2, 0, 0, 0, 0, 0, 8, 1, 0, 0, 0, /* truncated after many pages of output */

[philipc]

I think this is probably an addr2line bug. It should ignore units that it can't parse.

[mstange]

Thanks, that works! I can get a proper stack from addr2line that way.