425399 - Allow querying by modules in crashing thread

Status: RESOLVED WONTFIX

(Socorro :: General, task, P4)

Description

[Jonathan Watt [:jwatt]]

It would be very useful for third party plugin vendors to be able to filter results based on the presence of their module in the stack. This will help them find top crashes caused by their plugin(s).

Comment 1

[(not currently active) Ted Mielczarek]

I thought we stored module name in the frames table, but it looks like we don't. We'd have to add that first before we can do this. Once we store module names, it should be pretty simple to allow querying them.

Comment 2

[Jonathan Watt [:jwatt]]

Oh. Does that require a change to the breakpad client shipped with Firefox? Is it a change that should block FF3?

Comment 3

[(not currently active) Ted Mielczarek]

No, it's just a server-side change.

Comment 5

[Chris Lawson (gone)]

(In reply to comment #3)
> No, it's just a server-side change.

Is there a bug filed on making that change? This has been languishing for almost two years now.

Comment 6

[Chris Lawson (gone)]

Oh, this bug seems focused on module *name*, too. For something like Flash Player, the same module name covers at least four (and probably a lot more) module IDs. Should I file a new bug for search-by-module-ID?

Comment 7

[(not currently active) Ted Mielczarek]

You could, but that seems less likely to be implemented. Putting the module name in the "frames" table seems pretty straightforward, but putting the module ID there doesn't make a lot of sense.

Comment 8

[Chris Lawson (gone)]

(In reply to comment #7)
> putting the module
> ID there doesn't make a lot of sense.

It does for Flash, at least, which 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.

Comment 9

[Austin King [:ozten]]

(In reply to comment #8)
Sort of relevant... We're adding search by plugin filename and plugin name in Bug#535829. We're actively building this now.

This will only work with out of process plugins, however.

Comment 10

[Chris Lawson (gone)]

I spun the module-ID part off as bug 541224.

Comment 11

[Laura Thomson :laura]

This is a 2.x feature.

Comment 12

[Philipp Kewisch [:Fallen][☁️📆]]

This would also be very helpful for the Calendar Team. Right now we have to be lucky that something with "cal" is in the signature, but it would be nice to see all Lightning crashes at once.

Comment 13

[Laura Thomson :laura]

Adrian, will 2.0 ES implementation solve this?

Comment 14

[[DEACTIVATED] Adrian Gaudebert]

I'm not sure I understand very well what has to be done. In the json schema I have "pluginVersion", "pluginName" and "pluginFilename", and a list of "addons". 

What you want is to search all crashes that have a given pluginName? I read in c#1 that :jwatt wants to search a "module in the stack". What does it mean? Should we search for a given name in the dump?

Comment 15

[Robert Kaiser]

I'd think that "module in the stack" means that one of the stack frames in the crashing thread is code from the searched module. Not sure if bug 480503 (search in other frames than "the signature") is in the cards yet.

Comment 16

[(not currently active) Ted Mielczarek]

This is probably blocked by bug 573100, since the data necessary for this is currently in the "raw dump" section in a nonstandard format.

Comment 17

[Jonathan Watt [:jwatt]]

(In reply to comment #15)
> I'd think that "module in the stack" means that one of the stack frames in
> the crashing thread is code from the searched module.

Yes, that's what I meant. Basically, while I was working for Joost, we wanted to know how often crashes were occurring under Joost plugin code and taking the browser down, and be able to find the crash data that would enable us to fix the problem.

Comment 18

[[DEACTIVATED] Adrian Gaudebert]

If the data you want to search for can be found in the dump, then as I said in bug 573100 this is fixed by ES.

Comment 19

[(not currently active) Ted Mielczarek]

It can be, but it's not straightforward. You'd need to find which thread is the crashing thread (from one of the first lines in the raw dump), then look for lines starting with that integer. Can we do that in ES?

Comment 20

[[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 21

[(not currently active) Ted Mielczarek]

I don't think this solves the exact use case here, similar to bug 541224. What we really want here is "search just in the crashing thread" not "search the entire raw dump".

Comment 22

[Lonnen :lonnen]

a.t.m.o has access to all the public crash data and can support arbitrarily computational queries for employees. The scope of non-mozilla use cases is really limited with the changes we've made to addons. Wontfix.