by design, the precq does not upload its symbols to the crash server.  it'd be extremely wasteful of resources on our side as well as the crash server.

i think we also skip generating of the .sym files.  and prob creating of the .debug tarball.  neither step is fast (GB of data).

iirc, autotest should take care of doing the symbolification and such.  i guess tast needs to do that too ?

Tast knows how symbolize minidump files (see the "tast symbolize" command), but it can't do that if it doesn't have debug symbols.

It also doesn't do it automatically, since it's slow and network-intensive unless you ask a devserver to symbolize for you, and that won't work if you're on the corp network. It's also usually unnecessary, since Autotest symbolizes crash files after it runs Tast in the lab. Maybe Tast should do it itself on VM builders, which don't wrap Tast within Autotest, though.

Perhaps the answer here is that I should make "tast symbolize" support automatically using e.g. betty-release/R72-11253.0.0's symbols for betty-pre-cq/R72-11253.0.0-b3122994. I'll give that a try. No idea if it'll work for all packages, but maybe it'll at least work for Chrome?

(It doesn't seem to work for Chrome, at least in this case.)

you have no guarantee that symbol/debug info for any other release will line up with the current build.  please don't try to rely on that.

the bots not uploading debug info to GS isn't the same thing as the debug info not being available on the bot.  you have the sdk & the build in it, and the debug info should be in there for code to access.

Thanks, that makes sense.

I'm repurposing this bug to track making Tast symbolize these crashes automatically. I'm going to add a -symbolize flag to the "run" subcommand, but I also need to make us smarter when symbolizing multiple crash dumps and add a way to disable downloading debug_breakpad.tar.xz files (because downloading those in the lab would be a good way to make infra people angry with me really quickly).