The stackwalker doesn't pick the code id of the devenum.dll module correctly
Categories
(Socorro :: Processor, task, P4)
Tracking
(Not tracked)
People
(Reporter: gsvelto, Unassigned)
References
Details
Crash 33f66af4-8d44-48b1-9920-5cadb0210130 is interesting. It's happening in a Microsoft DLL (ntdll.dll) called in turn by another Microsoft DLL (devenum.dll). The stackwalker can't find the correct symbol file for the latter even though it is available. Calling minidump_dump on the minidump reveals that devenum.dll has a code id ECBE21931f000 but apparently no debug file or debug id. This seems to confuse the stackwalker which bails out and doesn't even try to find the symbols.
I wonder if it's possible to find a workaround for this scenario, like falling back on the code id. This is not urgent so low priority and low severity given it touches only a handful of crashes.
|
||
Comment 1•4 years ago
|
||
This sounds like a bug in minidump-stackwalk. If that sounds right, I can move it over.
If it's not a minidump-stackwalk bug, I'm not sure what we can do about it in the Socorro processor. I don't think there's enough information in the modules section to fill in the bits correctly and even if we did do that, it's after minidump-stackwalk has finished its work so it wouldn't help for symbolication or stack unwinding.
Gabriele: Is this a minidump-stackwalk bug? If not, what do you think we should do in the Socorro processor to alleviate it?
|
Reporter | |
Comment 2•4 years ago
|
||
Yes, definitely a minidump-stackwalk bug. I should move it there and close this.
|
|
||
Comment 3•4 years ago
|
||
Gabriele: Is this still a problem now that we've switched stackwalkers?
|
||
Comment 4•4 years ago
•
|
||
rust-minidump also gives up if you don't have a debug_id and debug_file. I wasn't aware there was an alternative, since those are the primary keys for Tecken queries. Like ok you can guess a .dll => .pdb, but I didn't think the debug_id and code_id were connected?
|
|
Reporter | |
Comment 5•4 years ago
|
||
(In reply to Gabriele Svelto [:gsvelto] from comment #2)
Yes, definitely a minidump-stackwalk bug. I should move it there and close this.
No, not yet. We have to figure out how to locate these files and it would require help from the symbol server or a two-step process in the stackwalker. Option 1 would be to allow stackwalkers to lookup symbol files via their code ID in addition to their debug ID; however I don't know how hard that would be... which brings us to option 2. Given that we have a code ID we can always find the corresponding DLL/EXE on the symbol server (at least for our files, we'd need to look on Microsoft symbol servers for their files). The stackwalker could download the DLL/EXE and extract the debug ID from there, then use that to fetch the symbol file. It's more roundabout but it wouldn't require changes to the symbol server; just an extra round-trip (and potentially an external one too for Microsoft DLLs).
|
|
||
Comment 6•4 years ago
|
||
Tecken doesn't keep track of metadata about the symbols files that would all us to look things up by debug id or code id. I wrote up bug #1746940 to cover that.
|
|
Reporter | |
Comment 7•2 years ago
|
||
This is fixed, I've confirmed it with a bunch of minidumps I had been lying around for this issue.
Description
•