Closed Bug 861500 Opened 12 years ago Closed 12 years ago

No symbols for major libraries on Firefox for Android and B2G or Flash debug symbols

Categories

(Socorro :: General, task)

Product:
Socorro
Component:
General
Platform:
All
Linux
Type:
task
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: scoobidiver, Assigned: lars)

References

Details

There have been no symbols for the XUL library on Firefox for Android since April 11, 20:45 UTC.
Ted, can you take a look at the symbol server and see if that's true? If so, where should this go to? RelEng?
Other libraries (mozalloc, mozglue, nss3, mozsqlite3) are affected and also B2G.
Summary: No symbols for XUL library on Firefox for Android since April 11, 20:45 UTC → No symbols for major libraries on Firefox for Android and B2G since April 11, 20:45 UTC
CCing glandium in case this is a toolchain or packaging related issue. I probably won't get a chance to look at this till Monday.
All channels are impacted not only the trunk so it's a bug in either Socorro 41 (see https://wiki.mozilla.org/Socorro:Releases) or servers.
I'd guess that it might be Socorro 41. Adding Laura so she knows.
OS: All → Linux
Blocks: 861769
This more and more sounds to me like the new processor is for some reason not using those symbols, given that we have bug 861776 as well.
new processor is missing symbol config. Bug 861830 filed to correct the problem
Blocks: 861915
Assignee: nobody → lars
Severity: critical → blocker
I don't think bug 861776 is a true dupe; altering the title here to more accurately reflect the problem.
Summary: No symbols for major libraries on Firefox for Android and B2G since April 11, 20:45 UTC → No symbols for major libraries on Firefox for Android and B2G or Flash debug symbols
It was fixed at 14:22 UTC for Flash, Firefox for Android and B2G.
the reprocessing is complete. However, I've noted that there are Flash crashes for which there still no symbols. Perhaps these are jumps into random memory with in the flash library and therefore there are no symbols? example: 34d04859-810a-4108-9a4e-540472130415 I reprocessed this crash, verified that the flash symbols were available, but still the signature has a signature of "npswf32.dll@0x14136a". As of 6:30 on Monday evening, there were 1976 crashes like this one. In contrast, there were zero crashes like this over the weekend. Looking further back to _before_ the new processor, I can see that there are many of crashes like this: 2937 on April 9th (two days before the new processor).
if the Flash issue in comment #12 warrants further investigation, please file a separate bug.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
(In reply to K Lars Lohn [:lars] [:klohn] from comment #12) > the reprocessing is complete. > > However, I've noted that there are Flash crashes for which there still no > symbols. Perhaps these are jumps into random memory with in the flash > library and therefore there are no symbols? example: > 34d04859-810a-4108-9a4e-540472130415 That one is an ancient Firefox (3.5.6) with an ancient Flash version (10.0.12.36, found by looking into modules). We don't care about those any more. There might be some (esp. older) Flash versions for which we are missing symbols, and that's OK. I'm only concerned if it's a recent Flash 11.6 or 11.7 version (which have the Flash version in their file names as well, e.g. npswf32_11_7_700_169.dll, npswf32_11_6_602_180.dll, npswf32_11_7_700_178.dll) and if it's recent, still supported (or at least "active" in Socorro terms) Firefox versions.
:glandium please check your crash to see if it has been reprocessed properly...
(In reply to K Lars Lohn [:lars] [:klohn] from comment #16) > :glandium please check your crash to see if it has been reprocessed > properly... Looks good. Thanks
You need to log in before you can comment on or make changes to this bug.