569825 - Socorro top hang analysis report

Status: RESOLVED WONTFIX

(Socorro :: General, task)

Description

[chris hofmann]

here is an idea for how we can improve the way we present "top hang" data for analysis.  

currently we just take the signatures for each side of the hang pair and count those in the top crash ranking report, but that doesn't help to breakdown the most frequent kind of paired hang events.

for instance "KiFastSystemCallRet" is generally listed as near the top of the top crash report, but there may be several hang pairs on the firefox side that are associated with that signature from the plugin side.  Here is a short breakdown of some of the firefox hang signatures that are assoicated with KiFastSystemCallRet

 238 plugin hang | KiFastSystemCallRet 
      -- \N hang | mozilla::plugins::PPluginInstanceParent::CallNPP_SetWindow(mozilla::plugins::NPRemoteWindow const&) 

 112 plugin hang | KiFastSystemCallRet 
      -- \N hang | mozilla::plugins::PPluginInstanceParent::CallUpdateWindow() 

 105 plugin hang | KiFastSystemCallRet --
      -- \N \N

 86 plugin hang | KiFastSystemCallRet --
   -- \N hang | mozilla::plugins::PPluginInstanceParent::CallNPP_Destroy(short*)

The basic process for reconstructing this kind of report would be to

 #  Get a sample of all the hang reports for a time period (say 1 day)

 #  filter the list to get a unique list of the hang_id for the time period

 #  Foreach unique_hang_pair

     # build a list the signatures for the plugin and firefox side of the hang pairs

 #  sort, count and rank the list of hang pairs


There are probably some ways to optimize those steps but the accomplish the basic requirements.   I'll attach a sample of what the basic output might look like.

Comment 1

[chris hofmann]

Attachment: top hang paris for 2010 06 01

sample of a hang pair analysis report showing the ranking of the hang pairs.  this should be linkified so we can get get at each of the signatures quickly. 

when building this prototype report I noticed in the data that the hang pairs don't get processed in a consistent order.  sometimes the plugin hang is process first and sometimes the firefox side of the hang is process first.  that leads to showing:

 105 \N \N -- plugin hang | KiFastSystemCallRet --
 103 plugin hang | KiFastSystemCallRet -- \N \N --

we would want to fix this by always listing the plugin side of the hang first.

Comment 2

[chris hofmann]

Attachment: same report with more spacing

Comment 3

[Robert Kaiser]

We have removed the browser-side of hang reports in bug 792082, and bsmedberg is completely reworking how we report and handle plugin hangs, so this is not how we'll do things in the future.