483184 - Check for crashes in [@ nsNavHistoryResult::OnEndUpdateBatch]

Status: RESOLVED FIXED

(mozilla.org Graveyard :: Server Operations, task)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

We had a couple of crashes in [@ nsNavHistoryResult::OnEndUpdateBatch] a while back which is handled by bug 434788. Now we want to know if the crashes still happen. Sadly we cannot search for signatures in sub-frames anymore since the latest update happened.

Could someone of you please run a check against 1.9.1 and 1.9.2 and report if there are still crash reports? Thanks!

Comment 1

[Aravind Gottipati [:aravind]]

Waiting for lars to give me the magic queries.

Comment 2

[Aravind Gottipati [:aravind]]

@Austin: can you look into this?

Comment 3

[K Lars Lohn [:lars] [:klohn]]

Whoops, I dropped the ball on that one as I was leaving MV a couple weeks ago.  I wrote a query to do this, but I could not get it return a result after a couple hours of execution time.  Not sure how to proceed.

Comment 4

[Austin King [:ozten]]

I am looking into this.
Please note: you can still perform this old query even though the Search form
has been changed. Instructions....

Create your search and hit "Filter Crash Reports".

Now take the url from the address bar and change
query=signature
into 
query=stack


Example:
1 day search against frames for NS_InvokeByIndex_P
http://crash-stats.mozilla.com/query/query?do_query=1&product=Firefox&version=Firefox%3A3.0.7&date=&range_value=1&range_unit=days&query_search=stack&query_type=exact&query=NS_InvokeByIndex_P

So you should be able to get what your looking for w/o us, unless the queries
are timing out, etc. If they are timing out or if there is a "too general query" error message, just keep reducing the scope of your search. Otherwise I acn recreate Lars' query.

Sorry I didn't mention this before.

Comment 5

[K Lars Lohn [:lars] [:klohn]]

Austin:  here's my notes from March 13 as I was waiting for my train:

select 
  r.uuid
from
  reports r join frames f on r.id = f.report_id 
                             and f.signature = 'nsNavHistoryResult::OnEndUpdateBatch'
                             and r.date_processed > timestamp without time zone '2009-03-09'
                             and f.date_processed > timestamp without time zone '2009-03-09'
    join branches b on r.product = b.product and r.version = b.version and b.branch in ('1.9.1', '1.9.2');

select 
  r.uuid
from
  reports r join frames f on r.id = f.report_id 
                             and f.signature = 'nsNavHistoryResult::OnEndUpdateBatch'
                             and r.date_processed >= timestamp without time zone '2009-02-26'
                             and r.date_processed < timestamp without time zone '2009-03-02'
                             and f.date_processed >= timestamp without time zone '2009-02-26'
                             and f.date_processed < timestamp without time zone '2009-03-02'
    join branches b on r.product = b.product and r.version = b.version and b.branch in ('1.9.1', '1.9.2');



select 
  count(*)
from
  reports r join frames f on r.id = f.report_id and f.signature = 'nsNavHistoryResult::OnEndUpdateBatch'
    join branches b on r.product = b.product and r.version = b.version and b.branch in ('1.9.1', '1.9.2')

Comment 6

[K Lars Lohn [:lars] [:klohn]]

In an unexpectedly lucid moment, I remembered that I had started some queries using screen back on March 13 just before I caught my train back to Oregon.  I looked and the results were still patiently waiting for me.

There is no evidence that this signature has been seen in the recent past.  I looked only as far back as 2009-02-16.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Thanks Austin. But changing the search type to stack always times out even with a lower day count. :/

Comment 8

[Aravind Gottipati [:aravind]]

Do you folks still need me to run any queries here or can I close this bug?

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Given comment 6 we could close this bug as fixed. Thanks for the feedback.