So there’s 4 types of crashes within the Fennec Native world right now.
1) Crashes that occur due to the Native UI which is caught by breakpad
2) Crashes that are caught by breakpad
3) Crashes that are caught by the OS but not breakpad
4) Crashes that neither breakpad nor the Android OS catches
In all of these cases, if you run into a crashing bug within fennec having a logcat helps out a lot. For crashes that happen in Native UI, those java crash stacks do appear in the logcat. In the other cases, it does help sometimes to see what the logcat is spewing during the time the crash is happening. So please please please try to use logcat and attach it to the bug. ( http://aaronmt.com/?p=503 or just as good is downloading alogcat. Pro tip: To get timestamps use command line : adb logcat -v time )
So let’s go back to point 1. So if you look at a crash now within Socorro that has a java crash :
https://crash-stats.mozilla.com/report/index/009e2d28-1fef-4b63-971c-efd782120217
You can see a new field that has the Java Stack! Yes, thanks to the socorro team and cpeterson, esp lars, and laura. That is hotness.
Point 2 is a matter of looking at Socorro.
Point 3/4 … if it’s released out in the Android Marketplace, there’s methods of getting the crashes from there. Otherwise : http://www.jnchen.com/blog/2011/11/updated-gdb#the__comments I haven’t tried to setup jimdb yet There’s other methods for nonFennec related apps. http://stackoverflow.com/questions/601503/how-do-i-obtain-crash-data-from-my-android-application
JimDB is probably going to be my second next project to look at leisurely at home. Currently, I want to finish getting robocop up and running and getting tests in for robocop.
Filed under: mobifx, mobile, Planet, QA, QMO, Uncategorized Tagged: mobifx, mobile, Planet, QMO 
