1774801 - Handle unloaded modules during signature generation

Status: RESOLVED DUPLICATE of bug 1746630

(Socorro :: Signature, task)

Description

[Gabriele Svelto [:gsvelto] (PTO)]

When we replaced the stackwalker we changed a bit of functionality on the stackwalker side which we forgot to adapt in Socorro, specifically how frames falling within unloaded modules are handled. Take this crash for example:

https://crash-stats.mozilla.org/report/index/e53f5ef1-7de4-4310-bf2e-bf8ff0220405#tab-details

With the old stackwalker the top frame looks like this:

      {
        "frame": 0,
        "missing_symbols": true,
        "module": "PrxDrvPE64.dll",
        "module_offset": "0x5387",
        "offset": "0x7ff8b0ee5387",
        "registers": {...},
        "trust": "context"
      },

This generates the signature: [@ prxdrvpe64.dll | QueryDnsForFamily].
The new stackwalker instead prints out this as the top frame:

      {
        "file": null,
        "frame": 0,
        "function": null,
        "function_offset": null,
        "line": null,
        "missing_symbols": true,
        "module": null,
        "module_offset": null,
        "offset": "0x00007ff8b0ee5387",
        "registers": {...},
        "trust": "context",
        "unloaded_modules": [
          {
            "module": "PrxDrvPE64.dll",
            "offsets": [
              "0x0000000000005387"
            ]
          }
        ]
      },

Note how the module field is null because we now have the unloaded_modules array with a list of unloaded modules that could contain this pointer. In this case there's only one but there could be more.

Because Socorro doesn't know about the unloaded_modules field it doesn't populate the module name and the signature becomes: [@ QueryDnsForFamily].

So, while we can do interesting things unloaded_modules on the short term we should just reproduce the old behavior by picking the first entry in the unloaded_modules array as the module name.

This will fix the issue we saw in crashes like bug 1698057 where the volume apparently dropped to zero because the crash was always happening within an unloaded module.

Comment 1

[Will Kahn-Greene [:willkg] ET needinfo? me]

I think this is a duplicate of bug #1746630 with some additional information. Does that seem right?

Comment 2

[Gabriele Svelto [:gsvelto] (PTO)]

Ah yes, I missed that one.