442234 - some breakpad processors not able to access symbols?

Status: RESOLVED FIXED

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

Description

[(not currently active) Ted Mielczarek]

Looking at the Firefox 3.0 topcrash list:
http://crash-stats.mozilla.com/topcrasher/byversion/Firefox/3.0

The #1 topcrash is nsBaseWidget::RemoveChild(nsIWidget*)
http://crash-stats.mozilla.com/report/list?range_unit=weeks&version=Firefox%3A3.0&range_value=2&signature=nsBaseWidget%3A%3ARemoveChild(nsIWidget*)

The #2 topcrash is xul.dll@0x154a4b
http://crash-stats.mozilla.com/report/list?range_unit=weeks&version=Firefox%3A3.0&range_value=2&signature=xul.dll%400x154a4b

Compare reports:
http://crash-stats.mozilla.com/report/index/55d817c0-428d-11dd-ac64-001321b13766
and
http://crash-stats.mozilla.com/report/index/0b708a54-439c-11dd-8acf-001a4bd43e5c

Same exact Build IDs, the modules have the same debug IDs, but one set of reports doesn't have symbols for some reason. The stacks in those sets of crash reports are the same, so it looks like some of our processors can't access the debug symbols.

Comment 1

[Aravind Gottipati [:aravind]]

Fixed now.  All new crash reports should now be processed correctly.  Sorry this took a while to resolve.

Comment 2

[Wayne Mery (:wsmwk)]

is bp-6cec46cc-4397-11dd-a1c7-001a4bd43e5c?date=2008-06-26-15 thunderbird crash an example of a symbols failure that is fixed?

and is it possible to respin the processing of the report to get symbols?

Comment 3

[Aravind Gottipati [:aravind]]

yeah, that one seems like it is missing symbols.  Unfortunately the app deletes processed reports after its done.  There is no way for us to re-process them (unless they failed).