Check for crashes in [@ nsNavHistoryResult::OnEndUpdateBatch]

RESOLVED FIXED

Status

mozilla.org Graveyard
Server Operations
RESOLVED FIXED
9 years ago
3 years ago

People

(Reporter: whimboo, Assigned: aravind)

Tracking

Details

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!
(Assignee)

Comment 1

9 years ago
Waiting for lars to give me the magic queries.
Assignee: server-ops → aravind
(Assignee)

Comment 2

9 years ago
@Austin: can you look into this?
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

9 years ago
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.
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')
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.
Thanks Austin. But changing the search type to stack always times out even with a lower day count. :/
(Assignee)

Comment 8

9 years ago
Do you folks still need me to run any queries here or can I close this bug?
Given comment 6 we could close this bug as fixed. Thanks for the feedback.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.