543776 - WARNING: Json file missing PluginName; iteration over non-sequence

Status: RESOLVED FIXED

(Socorro :: General, task)

Description

[Benjamin Smedberg]

At least some plugin-process crash reports are seeing the following:

WARNING: Json file missing PluginName; iteration over non-sequence
http://crash-stats.mozilla.com/report/index/69968756-80ec-4caa-9ce2-74c472100202

Comment 1

[Benjamin Smedberg]

Attachment: Dump file

Comment 2

[Benjamin Smedberg]

Attachment: .extra file

Comment 3

[Benjamin Smedberg]

I did get this to work once though, report at http://crash-stats.mozilla.com/report/index/400a3d1a-9d43-4430-9934-2456e2100202

FWIW, I'm using the testcase at bug 543770 to reproduce:
Windows, latest Java, Minefield
visit http://www.java.com/en/download/help/testvm.xml

Comment 4

[Austin King [:ozten]]

I've reproduced this.

When ProcessType = 'plugin' the code expects PluginFilename, PluginName, and PluginVersion to be present. I misread the part about all parts being optional in Bug#535829. I read it as specific process context will be optional depending on ProcessType.

The Bug:
It's skipping processing the plugin info, which would be fine, but there is a TypeError in how it skips over.

1) Can we make the contract be that if ProcessType='plugin' then PluginFilename, PluginName, and PluginVersion are present in the metadata, even if they contain an empty string?
2) Or I can relax this to Any of PluginFilename, PluginName, or PluginVersion are not empty then we insert into the plugins db.

I'll update our code to fix the TypeError issue. Please let me know if we want to do #1 or #2. The Database Schema is written for #1.

Comment 5

[(not currently active) Ted Mielczarek]

It makes no difference to me. It's probably two lines of code to send empty data for those fields.

Comment 6

[Benjamin Smedberg]

#2, but we'll alter the client in the meantime.

Comment 7

[(not currently active) Ted Mielczarek]

bsmedberg landed http://hg.mozilla.org/mozilla-central/rev/e2119ce306c0 as a client fix.

Comment 8

[Austin King [:ozten]]

Filed IT request to stage this fix Bug#544022.

Comment 9

[Austin King [:ozten]]

Submitted attached files to stage:
http://crash-stats.stage.mozilla.com/report/index/3147040c-9c9e-4dce-8774-297862100203

Looks good.

Feel free to test http://crash-reports.stage.mozilla.com/submit

Comment 10

[Austin King [:ozten]]

This was pushed to production.

reed reported a new error:
http://crash-stats.mozilla.com/report/pending/2e0065a7-d7c2-4997-a17c-03e302100203

I am now getting this error in stage also.
http://crash-stats.stage.mozilla.com/report/pending/98dd2203-49b3-4666-92c7-74ef32100203

Investigating.

Comment 11

[Benjamin Smedberg]

The client-side workaround doesn't seem to be working: even with the extra two keys PluginName= and PluginVersion= we're still getting this error with nightlies:

http://crash-stats.mozilla.com/report/index/bp-8efb816a-c45d-4cec-90b2-566f02100205

This is very serious because it means that all plugin-side crashes are not getting even the normal signature/stack information.

Comment 12

[Austin King [:ozten]]

I've reverted r1731:1718 which introduced some changes that shouldn't have gone to production. Additionally, we've added another prod bug fix for extension data. 

I can not account for why they didn't fail in staging during the last push.

We are re-deploying, I'll update the bug when this is on stage.

Comment 13

[Austin King [:ozten]]

(In reply to comment #11)
Changes are staged.

Please test https://crash-reports.stage.mozilla.com/submit if you can easily point breakpad at that instead of production.

I've simulated the attachements to this bug again and have:

http://crash-stats.stage.mozilla.com/report/index/24d9830f-1cc0-4935-bcbc-53b1f2100205

Which looks pretty good.

Comment 14

[Austin King [:ozten]]

Attachment: json file used to submit to collector (equivelent to extra)

For completeness, this is how I simulated Attachment 424806 [details] on Wednesday and today.

Comment 15

[Austin King [:ozten]]

Bug#544552 - Prod deployment bug.

Comment 16

[Austin King [:ozten]]

This is deployed.

Good News:
oopp simulated - Good
https://crash-stats.mozilla.com/report/index/cebea0a7-fb0f-4e89-aa2d-ec1892100205

normal crash - Good
https://crash-stats.mozilla.com/report/index/5ec19f7f-d820-4bb7-8675-04d0b2100205




Bad News:
Test Plugin-in on yesterdays (or wed) nightly with dom.ipc.plugins.enabled = True
on http://mavra.perilith.com/~luser/test-plugin-crash.html
OK, but no Plugin Metadata
http://crash-stats.mozilla.com/report/index/0827cec3-6f4e-4871-a915-817f02100205

Currently nightly
Same http://crash-stats.mozilla.com/report/index/2d7a21ba-4d9e-4d55-8673-503ca2100205

Comment 17

[(not currently active) Ted Mielczarek]

Yeah, I'm an idiot, I forgot that testing with OS X would not actually test this.

Comment 18

[Austin King [:ozten]]

Sigh/W00t!

Sigh. Nightly Windows XP - Bad processor behavior still.
http://crash-stats.mozilla.com/report/index/acb7e6c3-d498-4e95-bcee-a1bed2100205

Another crash posted moments apart...
Success
http://crash-stats.mozilla.com/report/index/bp-9ee290d4-31b6-49e2-9742-d07622100205

So we may still have an old processessor that needs to be restarted.

I'll do more verification.

Comment 19

[Austin King [:ozten]]

Okay, some stale servers are getting restarted.

Please let me know if you have any issues.