when missing debug id, stackwalker doesn't request symbol file from symbol server?

[Will Kahn-Greene]

I'm working on a change to Tecken where if it gets a download API url like this:

https://symbols.stage.mozaws.net/xul.pdb/000000000000000000000000000000000/xul.sym?code_file=xul.dll&code_id=64E782C570C4000

Tecken will see the bogus debug id and the code_file and code_id. It'll then do a lookup against a db table of information from symbol files that have been uploaded to find the debug_id for that code_file/code_id combination. If it finds a debug_id, it'll return an HTTP 302 with the download API url with the correct debug id. I've got this all working in the staging environment.

However, when I run the stackwalker using the staging environment as the symbol supplier, it looks as though the stackwalker sees 000000000000000000000000000000000 as a missing debug id and doesn't even try to download the symbol file like we thought it would.

Example:

Using crash report: 421408bf-aa63-4e5e-8af9-8ee3a0230907

minidump-stackwalk \
    --evil-json=raw_crash.json \
    --output-file output.txt \
    --verbose trace \
    --no-color \
    --symbols-url="https://symbols.stage.mozaws.net"

It should be trying to fetch this symbol file which exists on the staging symbol server:

https://symbols.stage.mozaws.net/uploads/files/file/71624

I see this in the trace:

TRACE unwind_thread{idx=0 tid=13572 tname="MainThread"}: starting stack unwind of thread 13572 MainThread
TRACE unwind_thread{idx=0 tid=13572 tname="MainThread"}: locating symbols for module C:\Program Files (x86)\Mozilla Firefox\xul.dll
TRACE unwind_thread{idx=0 tid=13572 tname="MainThread"}:symbols{file="xul.dll"}:symbols{module="xul.dll"}:locate_file{file_kind=BreakpadSym module="xul.dll"}: SimpleSymbolSupplier search
TRACE unwind_thread{idx=0 tid=13572 tname="MainThread"}:symbols{file="xul.dll"}:symbols{module="xul.dll"}:locate_file{file_kind=BreakpadSym module="xul.dll"}: SimpleSymbolSupplier could not build symbol_path
TRACE unwind_thread{idx=0 tid=13572 tname="MainThread"}:symbols{file="xul.dll"}: HttpSymbolSupplier search (SimpleSymbolSupplier found nothing)
TRACE unwind_thread{idx=0 tid=13572 tname="MainThread"}:symbols{file="xul.dll"}: HttpSymbolSupplier trying symbol server https://symbols.stage.mozaws.net/
TRACE unwind_thread{idx=0 tid=13572 tname="MainThread"}:symbols{file="xul.dll"}: HttpSymbolSupplier failed: the debug file or id were missing

Further, I see nothing in the logs for the staging environment suggesting anything requested /xul.pdb/000000000000000000000000000000000/xul.sym?code_file=xul.dll&code_id=64e782c570c4000.

Am I correct in that the stackwalker doesn't attempt to download symbols from the http symbol supplier if the debug id is missing?

If that's true, then should we change that behavior? Otherwise the changes for bug 1746940 will have no effect.

[Will Kahn-Greene]

Whoops--I got my data wrong. Let me redo this and see if it's a pilot error.

[Will Kahn-Greene]

I redid the testing and fixed some things which were wrong, but not relevant here. This is still not working for me--the stackwalker seems to see the missing debug id and doesn't try an HTTP request at all.

[Will Kahn-Greene]

I noticed that there is no debug_file either:

{
    "base_addr": "0x69920000",
    "cert_subject": "Mozilla Corporation",
    "code_id": "64e782c570c4000",
    "corrupt_symbols": false,
    "debug_file": "",
    "debug_id": "000000000000000000000000000000000",
    "end_addr": "0x709e4000",
    "filename": "xul.dll",
    "loaded_symbols": false,
    "missing_symbols": true,
    "symbol_url": null,
    "version": "117.0.0.8636"
},

That's true of all the crash reports that I spot checked that have the bogus debug id. So the stackwalker is doing the right thing in this case. Closing this out.