541224 - Allow querying by module IDs in crashing thread

Status: RESOLVED FIXED

(Socorro :: General, task)

Description

[Chris Lawson (gone)]

+++ This bug was initially created as a clone of Bug #425399 +++

From comment 6 through comment 8 in that bug...

For something like Flash Player, the same module name covers at least four (and probably a lot more) module IDs.

Flash, at least, seems to spawn a fresh signature for existing crashes every time they release a new version with the same old module name ("Flash Player"). The only reason we can tell the difference between the 10.0 releases and the 10.1 betas is because they *did* update it for the beta. Based on past experience, though, I doubt the new module name will *stay* different for the 10.1 release.

Considering Flash is *by far* our biggest third-party crasher, I'd say that's a
pretty strong argument for figuring out a way to search module IDs. We don't have to display them in the "Crashing Thread" table, but they definitely need to be searchable somehow.

Comment 1

[Benjamin Smedberg]

When you say "Module ID" do you mean something like "6C47C5CE1F204257B9859572855CBB2C2"? Yes, querying by that ID would let you distinguish very particular versions of DLLs, but how does that help?

On the other hand, I'm not sure what "module name" means to you either... do you mean the filename (NPSWF32.dll)? Why would it be more useful to search for "crashes that have the module with ID 906B45AF454E42B29C10F9ED78C111041 in the stack" instead of "crashes that have the module NPSWF32.dll in the stack"?

If this is for some sort of automated procedure, can't you do the general query and then use the JSON output to filter the results until you have the desired level of specificity? Adding a feature to the UI (and the necessary data columns to support it) sounds like undesirable overkill.

Comment 2

[Chris Lawson (gone)]

If you can describe a better way to search for a specific Flash module ID within a given signature other than what I proposed here, I'm all ears :)

Basically, if we're asked a question like "Does this crash signature occur with multiple Flash versions", there's no way to answer that short of going through every single crash report with that signature and comparing Flash module IDs manually.

Comment 3

[(not currently active) Ted Mielczarek]

"Module ID" is basically a hash of the module, which is why it changes with every new build.

Comment 4

[Chris Lawson (gone)]

(In reply to comment #3)
> "Module ID" is basically a hash of the module, which is why it changes with
> every new build.

Right, and since Adobe can't be arsed to change anything *else* about Flash, module IDs are only way I know of to differentiate Flash versions in Breakpad. Am I missing something?

Comment 5

[Laura Thomson :laura]

Full text search of dumps should enable this (a goal post the hbase switch) I think.

Comment 6

[Laura Thomson :laura]

2.x

Comment 7

[Laura Thomson :laura]

Will 2.0 solve this, Adrian?

Comment 8

[[DEACTIVATED] Adrian Gaudebert]

If it is just searching into the dump for a string, yes, the ES implementation should already solve that. I have to test though.

Comment 9

[(not currently active) Ted Mielczarek]

It's not that simple, no. However, the original impetus for this bug is not a problem anymore, since we have flash player symbols nowadays.

Comment 10

[(not currently active) Ted Mielczarek]

This probably needs bug 573100 to be usefully implemented.

Comment 11

[[DEACTIVATED] Adrian Gaudebert]

Can the Module ID be found in the dump? I'm not sure about that.

Comment 12

[(not currently active) Ted Mielczarek]

Yes, we list all the modules in the dump, but the module ID is not listed in the stack trace, so you'd have to connect the two pieces of data.

Comment 13

[[DEACTIVATED] Adrian Gaudebert]

It is now possible to search for a string in the dump with supersearch. For example: https://crash-stats.mozilla.com/search/?product=Firefox&dump=32F2F05378264956B2A803A7A650551B2

I think this solves this bug. If it doesn't, please reopen.

Comment 14

[Benjamin Smedberg]

Note that this doesn't precisely solve the problem in the summary, which is querying "in the crashing thread". But I don't think that actually matters in almost any case in practice, so I'm happy to leave well enough alone ;-)