(In reply to Nicholas Nethercote [:njn] from comment #0)
> I also don't know what the "const" and "str" entries mean.
Those look like stack scanning gone wrong — when breakpad has no other way to unwind, it picks up anything on the stack that looks like a return address. So it can yield stack frames that already returned (the fmt:: frames look like that), and apparently also picked up some pointers into .rodata in some cases. (It can also cause the more precise unwinding tactics to be applied to a partially-overwritten stack frame and yield additional garbage, and that can be seen happening here in the "Raw Dump" tab on crash-stats, but none of those turned up anything with a name, so they're not in the listings pasted above.)
The first two traces use stack scanning immediately after the initial rust_panic context, so they're not very trustworthy. The third one uses frame pointer unwinding up to mp4parse_read, so that's at least a vague approximation of how things will look once bug 1268617 and related fixes start being used. I don't know offhand if Socorro uses the "trust" key from the stack frames, but if that's why it's not including anything past "rust_panic" there then that will hopefully be fixed soon.
And as for that third stack… it seems to me that, given "rust_panic", those next 4 frames don't add any information, and the next meaningful one is mp4parse_read; i.e., we'd want to suppress the panic internals while including frames after them, which I assume we already have some way to do for Gecko C++ assertion/panic stuff? But note that https://github.com/rust-lang/rust/pull/32900 just changed most of the names in question.

> And as for that third stack… it seems to me that, given "rust_panic", those
> next 4 frames don't add any information, and the next meaningful one is
> mp4parse_read; i.e., we'd want to suppress the panic internals while
> including frames after them, which I assume we already have some way to do
> for Gecko C++ assertion/panic stuff?
If I understand the question correctly, the way to do it is via these regexp lists, such as prefix_signature_re, which give Socorro control over how stack frames get added to the crash signature -- you can use these lists to ignore certain stack frames, or to include them in the signature but also request that the subsequent stack frame be considered.

Sorry for taking this long getting to this. I have recently been working on making it a lot easier for users to edit those signatures lists themselves. We now have them in separate text files in our repo, and I wrote some documentation to help people make changes there. All of that is here: https://github.com/mozilla/socorro/tree/master/socorro/siglists
Nicholas, would you like to give it a try and make those changes yourself? We can meet in London to do that if you want. Feedback on that process would be appreciated of course, we are doing this to make the whole process of updating the skip lists easier and faster for everyone. :)

It looks like we still don't have any correctly unwound Rust crashes on crash-stats yet, or at least nothing that comes up in a search for rust_panic, but locally produced/processed crashes might be usable for figuring out the signature generation settings (I haven't tried).

So from our discussion in the oxidation meeting in London, the consensus was that the stacks are being unwound correctly, we will just get some incorrect symbols in frames from libstd/libcore because we don't have debug symbols there. I can't actually find any `rust_panic` reports from any builds that have the fix for bug 1268617, so I'm not totally sure how to proceed here.
I did have an insight at the end of the oxidation meeting--if we do want to handle all `rust_panic` crashes similarly, we probably want to put that frame into the "Signature Sentinels" list:
https://github.com/mozilla/socorro/tree/master/socorro/siglists#signature-sentinels