With some recent improvements in crash-stats data[1], we now have the ability to report on which crashes don't have the necessary symbols to produce a useful crash signature. I have generated the following reports from yesterday's crash data:

https://crash-analysis.mozilla.com/bsmedberg/missing-symbols.20131208.byname.csv
https://crash-analysis.mozilla.com/bsmedberg/missing-symbols.20131208.csv

The "byname" report just looks at which DLL names are missing. The other reports specifically on which DLL versions are missing.

Summary:

* The out-of-memory issue is causing us not to record symbol information for xul.dll in Firefox 25. This was fixed in Firefox 26[2] * by a large margin graphics drivers are the big problem: Nvidia (nvwgf2um.dll/nvumdshim.dll/nvapi.dll/nvd3dum.dll), Intel (igdumd32.dll/igd10umd32.dll/igd10iumd32.dll) and ATI/AMD (atidxx32.dll/atiumdag.dll). * We are missing some Windows symbols (user32.dll/mf.dll and a few others). These are usually available from the Microsoft symbol server, so I will follow up on this to figure out why they aren't working correctly.
* Some probably-malware is showing up: sdata.dll
* Some 3rd-party software of dubious quality is showing up: radhslib.dll is Naomi Internet Filter, bug 725503. gbmzh_uni.dll is bug 838568.
* Java is npjp2.dll and jvm.dll
... and there's a very long tail

Overall, I don't think there is much immediate action we can take to make this better. Long-term, we should continue working with partners such as graphics card vendors to get encrypted symbols for the user-mode drivers. https://developer.mozilla.org/en-US/docs/Crash_Reporting_Guide_for_Firefox_OS_Partners#Upload_Symbols_to_Mozilla has some details about how they can provide Mozilla with encrypted symbols that would improve stackwalking and crash signature analysis.

--BDS

_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to