578687 - Add support for Content crashes (tracker)

Status: VERIFIED FIXED

(Socorro :: General, task)

Description

[Laura Thomson :laura]

Jetpack crashes will be ProcessType=jetpack
Content crashes will be ProcessType=content
Jetpack crashes will also have a JetpackID and a JetpackName

Todo list:
- Add Hbase support (deinspanjer)
- Add PG support (lars or ozten)
- Changes to processor (lars)
- Changes to UI (ozten/ryan/laura)
- Icons for the UI (chowse)

bsmedberg says these will start appearing in about two weeks but we can push this out in 1.8, no need for a special release.

I'll file separate bugs shortly.

Comment 1

[Austin King [:ozten]]

Can we attach a raw dump and meta file for the both a Jetpack and a Content crash?

Comment 2

[Benjamin Smedberg]

I think the best thing to do for testing now is just take an existing plugin crash report, change the ProcessType=jetpack and ProcessType=content and use that for testing. The final metadata may change a little, but the basics won't. I won't have real product submissions until beta3 at this point, and even that might not have UI.

Comment 3

[K Lars Lohn [:lars] [:klohn]]

The meta data is the problem.  If we don't know what it looks like, we can't make appropriate changes to the database to accommodate it.  We're not sure if we need to make an additional table or if it can just be appended to a reports record.  

JetpackID and JetpackName - what are their types and associated data lengths?  Is a JetpackID unique enough to identify a JetpackName?  Or are they unique only when taken together?  

If there are other metadata fields coming too, it might have a major impact on how this gets implemented.  I'm really uncomfortable making database schema changes that could suddenly be found sub-optimal or completely wrong.  It's painful to change the database once it gets pushed to production.

Comment 4

[Benjamin Smedberg]

ok, what I want for the short term is no additional metadata other than the existing processtype stuff. I don't think we'll know much about jetpackid/jetpackname until the jetpack guys actually start getting crashes and figure out how they want to correlate and present that data.

Comment 5

[Austin King [:ozten]]

(In reply to comment #4)
This sounds like we need to support search by process_type, but we will not support searching for specific Jetpacks by name.

So process_type = 'jetpack' or 'content' in the reports tables and punt on features that would require the metadata.

Comment 6

[(not currently active) Ted Mielczarek]

FYI content process crash reporting has landed for Fennec, bug 581335. They're not currently setting ProcessType=content, I filed bug 614610 on that.

Comment 7

[Benjamin Smedberg]

Jetpack crash reports are also going to start being submitted with beta8, at least in some cases.

Comment 8

[Laura Thomson :laura]

Can we get some sample crashes, bsmedberg?

Comment 9

[Benjamin Smedberg]

What do you mean by sample crashes? Local minidump files, or local JSON files that go with the miniidumps, or crash IDs that have already been submitted?

Comment 10

[Laura Thomson :laura]

I think (minidump and json) or (ID for one that has been submitted) would be excellent.

Comment 11

[Benjamin Smedberg]

Jetpack: http://crash-stats.mozilla.com/report/index/7d6c6805-cec9-4f71-ba93-f61d42101129

Content: https://crash-stats.mozilla.com/report/index/9d0fafb8-3611-4300-beb5-2ff672101129

Note that these don't have the ProcessType property in the JSON yet, that still needs to be implemented in bug 614610.

Comment 12

[Benjamin Smedberg]

I tried to submit http://crash-stats.mozilla.com/report/pending/e0896b54-26b0-4553-b9c6-bed9c2101129 with a correct ProcessType, but it's not responding, so I suspect that socorro isn't accepting ProcessType=jetpack yet.

Comment 13

[Laura Thomson :laura]

We need to get as much of this done for 2.1 as possible.

Comment 14

[K Lars Lohn [:lars] [:klohn]]

:bsmedberg: I took a look at your e0896b54-26b0-4553-b9c6-bed9c2101129 crash. It did process and correctly shows the process_type == jetpack.  Looking at the raw dump received by the collector however, I don't see any additional meta data in the form of JetpackID and JetpackName.  Is that a breakpad feature that doesn't exist yet?

Comment 15

[K Lars Lohn [:lars] [:klohn]]

here's my pending questions that I need with regards to jetpack crashes:

Is a JetpackID unique enough to identify a JetpackName or are they unique only when taken together?  Or is it unique only when the crash ooid/uuid is included?

What are their types and associated data lengths?

Comment 16

[Benjamin Smedberg]

I'm not sure what "unique enough to identify a jetpack name" means. Jetpack IDs are the unique identifiers for the extension. The name is just a human-readable extension name so that we don't have to use AMO or something to map IDs back to extensions.

They are both strings of indeterminate length.

But really, we disabled jetpack processes in Firefox 4 beta and haven't turned them back on, so content crashes are by far the higher priority.

Comment 17

[K Lars Lohn [:lars] [:klohn]]

you've actually answered the question.  There is a 1:1 relationship between the id and the name.  You could send just the id and we'd still have enough information to associate the crash with a specific jetpack.  Because you're sending both, I was concerned that the relationship wasn't 1:1.

We'll likely implement this with a new 'jetpack' table containing ids and names.  The reports table will have only the id.

Comment 18

[Benjamin Smedberg]

It is possible that multiple jetpacks will have the same name (but different IDs), so it's technically 1:many, and its reasonably likely that a jetpack name may change over time. But those are probably not important details...

Comment 19

[Laura Thomson :laura]

Jetpack crashes are off the radar for now.

Last remaining Content bugs are slated for 2.2 and later: pushing tracker out.

Comment 20

[Laura Thomson :laura]

Dependent bugs are still open, moving

Comment 21

[Lonnen :lonnen]

Last dependent bug is in a different milestone. Moving.

Comment 22

[Lonnen :lonnen]

At long last...

Comment 23

[Matt Brandt [:mbrandt]]

Dependent bugs have been verified. Automation and manual bfts are passing.