{"id":1017,"date":"2015-04-20T13:45:41","date_gmt":"2015-04-20T17:45:41","guid":{"rendered":"http:\/\/benjamin.smedbergs.us\/blog\/?p=1017"},"modified":"2019-12-19T11:03:39","modified_gmt":"2019-12-19T15:03:39","slug":"using-crash-stats-api-magic","status":"publish","type":"post","link":"https:\/\/benjamin.smedbergs.us\/blog\/2015-04-20\/using-crash-stats-api-magic\/","title":{"rendered":"Using crash-stats-api-magic"},"content":{"rendered":"

A while back, I wrote the tool crash-stats-api-magic<\/a> which allows custom processing of results from the crash-stats API. This tool is not user-friendly, but it can be used to answer some pretty complicated questions.<\/p>\n

As an example and demonstration, see a bug<\/a> that Matthew Gregan<\/a> filed this morning asking for a custom report from crash-stats:<\/p>\n

In trying to debug bug 1135562, it’s hard to guess the severity of the problem or look for any type of version\/etc. correlation because there are many types of hangs caught under the same mozilla::MediaShutdownManager::Shutdown stack. I’d like a report that contains only those with mozilla::MediaShutdownManager::Shutdown in the hung (main thread) stack *and* has wasapi_stream_init on one of the other threads, please.<\/p><\/blockquote>\n

To build this report, start with a basic query and then refine it in the tool:<\/p>\n

    \n
  1. Construct a supersearch query<\/a> to select the crashes we’re interested in. The only criteria for this query was “signature contains ‘MediaShutdownManager::Shutdown`. When possible, filter on channel, OS, and version to reduce noise.\n
  2. After the supersearch query is constructed, choose “More Options” from the results page and copy the “Public API URL” link.\n
  3. Load crash-stats-api-magic<\/a> and paste the query URL. Choose “Fetch” to fetch the results. Look through the raw data to get a sense for its structure. Link<\/a>\n
  4. The meat of this function is to filter out the crashes that don’t have “wasapi_stream_init” on a thread. Choose “New Rule” and create a filter rule:\n
    function(d) {\r\n  var ok = false;\r\n  d.json_dump.threads.forEach(function(thread) {\r\n    thread.frames.forEach(function(frame) {\r\n      if (frame.function && frame.function.indexOf(\"wasapi_stream_init\") != -1) {\r\n        ok = true;\r\n      }\r\n    });\r\n  });\r\n  return ok;\r\n}<\/pre>\n
    Choose “Execute” to run the filter. Link<\/a><\/p>\n
  5. To get the final report we output only the signature and the crash ID for each result. Choose “New Rule” again and create a mapping rule:\n
    function(d) {\r\n  return [d.uuid, d.signature];\r\n}<\/pre>\n
     Link<\/a>\n<\/ol>\n
    One of the advantages of this tool is that it is possible to iterate quickly on the data without constantly re-querying, but at the end it should be possible to permalink to the results in bugzilla or email exchanges.<\/p>\n
    If you need to do complex crash-stats analysis, please try it out! email me if you have questions, and pull requests<\/a> are welcome.<\/p>\n","protected":false},"excerpt":{"rendered":"
    A while back, I wrote the tool crash-stats-api-magic which allows custom processing of results from the crash-stats API. This tool is not user-friendly, but it can be used to answer some pretty complicated questions. As an example and demonstration, see a bug that Matthew Gregan filed this morning asking for a custom report from crash-stats: […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[303,50],"class_list":["post-1017","post","type-post","status-publish","format-standard","hentry","category-mozilla","tag-crash-stats-api-magic","tag-socorro"],"_links":{"self":[{"href":"https:\/\/benjamin.smedbergs.us\/blog\/wp-json\/wp\/v2\/posts\/1017","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/benjamin.smedbergs.us\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/benjamin.smedbergs.us\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/benjamin.smedbergs.us\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/benjamin.smedbergs.us\/blog\/wp-json\/wp\/v2\/comments?post=1017"}],"version-history":[{"count":10,"href":"https:\/\/benjamin.smedbergs.us\/blog\/wp-json\/wp\/v2\/posts\/1017\/revisions"}],"predecessor-version":[{"id":1027,"href":"https:\/\/benjamin.smedbergs.us\/blog\/wp-json\/wp\/v2\/posts\/1017\/revisions\/1027"}],"wp:attachment":[{"href":"https:\/\/benjamin.smedbergs.us\/blog\/wp-json\/wp\/v2\/media?parent=1017"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/benjamin.smedbergs.us\/blog\/wp-json\/wp\/v2\/categories?post=1017"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/benjamin.smedbergs.us\/blog\/wp-json\/wp\/v2\/tags?post=1017"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}