* query all of the Flash plugin hangs on the release channel for a particular day * look at the stack for the main thread (thread 0) of the plugin process * the crash matches if that stack contains "AccessibleObjectFromEvent" I want to know what % of the hangs match this pattern.
I tried to do this but I can't using spectateur because spectateur/supersearch currently can't do sampling, and I couldn't write a script to fetch 20k crash reports. It would be really nice to have this answer on Monday. Adrian is this something you can take? If it helps for development, https://crash-stats.mozilla.com/report/index/e3850bd6-ed92-4f47-b5fd-013792150215 should match the pattern.
Adrian is out all week and then some. We'll have to find someone else.
I think the attached SQL will do it (we could probably use a custom ES query but I am not sure how to write this query offhand)
Assignee: nobody → rhelmer
Status: NEW → ASSIGNED
Attachment #8570994 - Flags: review?(sdeckelmann)
Attachment #8570994 - Attachment mime type: text/x-sql → text/plain
Same as before, but use 'threads'->0 not 'crashing_thread'
Attachment #8570995 - Attachment mime type: text/x-sql → text/plain
(In reply to Robert Helmer [:rhelmer] from comment #3) > Created attachment 8570995 [details] > bug1138078.sql > > Same as before, but use 'threads'->0 not 'crashing_thread' The result of this query for 2015-02-15 (same as the linked crash from comment 0) is 2.7% : """ total ------- 18769 accessibleobjectfromeventcount -------------------------------- 508 """ bsmedberg, the user story says "query all of the Flash plugin hangs on the release channel for a particular day" - which day(s) did you want? You should be able to run the attached query yourself if you'd like (assuming it looks correct for what you're after), it took ~6 minutes to run both queries for me for a single day.
It doesn't matter which day. I just wanted it to be a 24-hour day to avoid locality skew. Thanks rhelmer. We should understand what our long-term story is for doing these kinds of queries: I think it's still spectateur with sampling improvements, but we shouldn't turn off direct DB access until that's better ;-)
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
(In reply to Benjamin Smedberg [:bsmedberg] from comment #5) > It doesn't matter which day. I just wanted it to be a 24-hour day to avoid > locality skew. Thanks rhelmer. Great! > We should understand what our long-term story is for doing these kinds of > queries: I think it's still spectateur with sampling improvements, but we > shouldn't turn off direct DB access until that's better ;-) I had the same thought - pretty sure this can be done via the "Custom query" in supersearch as well (not sure spectateur can do it until the supersearch API has access to the json dump), but wanted to get this done quickly since the SQL was easy.
Comment on attachment 8570994 [details] bug1138078.sql In the first query, you could get the signature from the raw_crash and avoid the join. It might be valuable to create an index for the array_elements.. maybe. These kinds of queries may benefit from JSONB and upgrading to Postgres 9.4.
You need to log in before you can comment on or make changes to this bug.