minidump-processor has support for fetching binaries from a symbol server and running dump_syms on them, but in principle minidump-debugger could go one step further and support you pointing it at a build dir/exe and running dump_syms on it.

This would probably be the most useful workflow for random users.

Bonus points if it can detect "what you did wrong" with your debug flags and recommend improvements?

https://github.com/Gankra/socc-pair/ has streamlined workflows for fetching minidumps from https://crash-stats.mozilla.org/

If enough people from mozilla use this in anger, it might be worth copying. Or if we can make it configurable enough that e.g. someone from sentry could use it for their backend too?

Clearing the checkbox makes the processor thread delete the directory before running, which is just really fuckin' spooky if you don't know that and accidentally set the string to something bad like the current dir! Ideally we should have a proper button which just enqueues a command for minidump-processor.

This requires a change to minidump-processor to give it a proper "queue" of commands because it will be the first command that is "TCP-like" and not "UDP-like". That is, currently there is only one buffered command because all the current commands basically obsolete whatever the processor is currently doing (hence why cancellation of the stackwalk is done by every command).

I think we do want some amount of cancellation though, so maybe there should be a queue of TCP-like commands and a single UDP-like command. Alternatively it might be desirable to also queue up the UDP-like ones too so that the processor is forced to ack-back even if it "notices" that the commands are obsoleted.

There is currently some mild racey-ness in the code where I believe in principle you could get the UI confused about which partial-processed report it's doing incremental updates too, although I don't think this is a very serious concern in practice, as it would require sending a lot of different commands in incredibly fast succession, and having the processor grab an update in the middle of that.

• option 1: make the current register display in ui_processed be double-columned, so we can increase vertical density

• option 2: make the register display just a free-form text box we manually layout (cf #4)

• option 3: put them nested under frames in the stackwalk

• option 4: same as option 3, but make it collapsable?

I'm inclined to 1 or 2, but 3/4 has precedent in minidump-stackwalk --human

In principle this UX question also extends to any future attempts to expose recovered function arguments.

Thanks to @marti4d, rust-minidump's print methods (which power "raw dump" views in this tool and minidump-stackwalk) have dope hexdump formatting. However we're an interactive display, and should in principle be able to:

• more interactively/prettily display those
• use the current pane's scroll to intelligently only render the visible subset

Right now there's a checkbox at the bottom of settings "hide memory dumps in raw mode" which is enabled by default that turns on the --brief output that supresses these dumps. The reason I have it flipped on by default is that in the current form there's no way to interactively "collapse" the dumps, and some of them are genuinely so long that they lag out the UI.

So my current workflow is to start with them off, find a region I want a hexdump for, uncheck the setting, and then go back and view it.

processed_state has info on whether symbols were missing/corrupt, where they were found, etc. That would be nice to surface, along with any other stats.