Closed Bug 1176129 Opened 9 years ago Closed 7 years ago

Add special view for Protected Mode Adobe Flash

Categories

(Socorro :: Webapp, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: bugzilla, Unassigned)

References

Details

Adobe engineers have told me that they would like to be able to select a plugin-container crash stack and drill down to see the most frequent FlashPlayer sandbox stacks that are associated with that particular plugin-container stack.

As is, the plugin-container stacks are not actionable to them because plugin-container is usually blocking on IPC. What they really need is to be able to see the stack of the sandbox process.

This feature, combined with bug 1176127, would greatly assist Adobe with addressing Flash crashes and hangs.
Can't we achieve that with a search? If so, we should probably go for that.
(In reply to Robert Kaiser (:kairo@mozilla.com) - on vacation or slow to reply until the end of June from comment #1)
> Can't we achieve that with a search? If so, we should probably go for that.

Adrian, is this doable ^? It'd help Adobe out a lot.
Flags: needinfo?(adrian)
I don't understand what this bug is about. Can anyone explain where exactly is the data that you want to access?
Flags: needinfo?(adrian)
(In reply to Adrian Gaudebert [:adrian] from comment #3)
> I don't understand what this bug is about. Can anyone explain where exactly
> is the data that you want to access?

With most plugin crash reports, we call stacks from two processes: browser and plugin-container. On Windows. Protected mode Adobe Flash involves two more processes. In addition to the first two, we also have call stacks for the Adobe "broker" and "sandbox" processes. When viewing plugin crashes, the default view is for the plugin-container call stack. For Adobe, that is insufficient for diagnosing Flash crashes and hangs in the 4-process situation. All four stacks are uploaded to Socorro and are available by the API, but not the web dashboards.
Flags: needinfo?(adrian)
OK, so as far as I understand this, it is not a Super Search bug. Correct me if I'm wrong. 

Considering this crash report - https://crash-stats.mozilla.com/report/index/74b49281-f45e-4ca9-9100-9ddb82150716 - which is on Firefox on Windows, with process type of "plugin" and a flash process dump of "sandbox" (found with Super Search: https://crash-stats.mozilla.com/search/?product=Firefox&process_type=plugin&platform=Windows&flash_process_dump=sandbox ), you want to show not only the crashing thread's stack trace but also some other stack traces. Is that right?

What I do not know however is where exactly, in Socorro's databases, is the data that you need. Does anyone know?
Flags: needinfo?(adrian)
Flags: needinfo?(aklotz)
Not quite.

bug 1176127 is for adding the ability to easily go from a plugin-container crash to the stacks from Flash processes at the time of the plugin-container crash. Benjamin Smedberg has a tool for this, so crash-stats just needs to link to the tool.

e.g. If I'm looking at https://crash-stats.mozilla.com/report/index/1bbfa583-6990-4d59-8a74-d6d952150704 I also want a link to this URL: http://bsmedberg.github.io/socorro-toolbox/html/multiple-minidumps.html?crashID=1bbfa583-6990-4d59-8a74-d6d952150704

This bug is about augmenting the plugin-container crash page to also list the Flash stacks **most commonly** associated with this plugin-container signature. 

e.g. if I'm looking at https://crash-stats.mozilla.com/report/index/1bbfa583-6990-4d59-8a74-d6d952150704 , I want to know that for this plugin-container signature, the most commonly associated Flash stack is:

0	MsgWaitForMultipleObjects
1	FlashPlayerPlugin_18_0_0_194.exe@0x1058fbe
2	FlashPlayerPlugin_18_0_0_194.exe@0x1044f7f

Aaron, correct me if I'm wrong
We have not gotten to this yet. I'm going to wontfix this for now. If someone thinks this is high value, please reopen.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(aklotz)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.