Bad line record addresses in Breakpad sym files can cause problems

[mstange]

Our Firefox dSYMs currently contain garbled debug data, which causes dump_syms to output bad data, which causes symbolic's parsing of the Breakpad sym file to produce bad data, which causes symcaches to contain bad data, which causes symcache lookups to return wrong functions.

Example:

% curl --compressed -L "https://symbols.mozilla.org/XUL/6117E38C063A30B0BC7B5A0A21F82B0F0/XUL.sym" -o XUL.sym
% cargo run --release -p symcache_debug -- -d XUL.sym --lookup 0x75045f
mozilla::storage::NullVariant::GetDataType()
  at hg:hg.mozilla.org/mozilla-central:mfbt/Span.h:60b4965aa0ca5a7a60c71229600092a65df8bc1d line 800

mozilla::storage::NullVariant::GetDataType() is incorrect - it only starts 5 bytes later, at 0x750464.
It should be returning mozilla::storage::Variant_base::Release() instead.

It would be nice to make sym parsing and processing more robust so that line records which extend before the function start cannot cause these kinds of inconsistencies.

[loewenheim]

I'm playing around with fixing this. Does

mozilla::storage::Variant_base::Release()
  at hg:hg.mozilla.org/mozilla-central:mfbt/Span.h:60b4965aa0ca5a7a60c71229600092a65df8bc1d line 800

sound correct?

[mstange]

Oh, nice, thanks! Yes, the function is correct, and the file and line are "correct".

With "correct" I mean that they match what the Breakpad file is saying, so it's the best symbolic can do here, but the file is saying nonsense - Variant_base::Release() is not actually defined in Span.h.