Closed Bug 442234 Opened 16 years ago Closed 16 years ago

some breakpad processors not able to access symbols?

Categories

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

task
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ted, Assigned: aravind)

References

()

Details

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.
Assignee: server-ops → aravind
Fixed now.  All new crash reports should now be processed correctly.  Sorry this took a while to resolve.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
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?
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).
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.