910024 - Find (device, android_version) pairs with only null crash addresses

Status: RESOLVED WORKSFORME

(Socorro :: Data request, task)

Description

[Mike Hommey [:glandium]]

In bug 907957, it was found that android 4.2.2 on the HTC One X and X+ doesn't give out useful information to the segfault handler. We would like to identify what other devices could be affected by this.

As it turns out, this missing information also means that crash reports for the HTC One X on android 4.2.2 (android_version = 17) all have a crash address of 0x0, even when the actual crash was not on that address.

After some fiddling after a direct request on IRC, selena validated that all 38 crash reports from HTC One X on android 4.2.x from last week have a crash address of 0x0.

To identify other devices/os combinations that would be affected with the same problem, we'd like a report with other device/android_version pairs that have the same pattern: all crashes with a crash address of 0x0.

It would also be useful to determine the threshold of crash number under which the result would not be significant (for example, 4 crashes all with a crash address of 0x0 may just be 4 actual null pointer crashes ; there must be a number of crashes above which there's a fair chance that there would normally be non-null pointer crashes)

Comment 1

[Selena Deckelmann :selenamarie :selena]

Working on a query here: https://gist.github.com/selenamarie/bdd2d0dea6e00944475a

Comment 2

[Mike Hommey [:glandium]]

Selena, do you have news on this?

Comment 3

[Selena Deckelmann :selenamarie :selena]

Having a look today. Sorry for the delay! EOQ and Summit back to back was rough.

Comment 4

[Selena Deckelmann :selenamarie :selena]

Updated the linked gist and attached pipe-delimited output. 

Columns are: 

count of crashes with crash address 0x0
android_version
android_model
count of crashes for this version/model at any crash address
total count of crashes with android information in this sample

Crashes are from last week. 

Let me know if you need a longer period of time. 

Regarding this: 

> It would also be useful to determine the threshold of crash number under which the result would not be significant (for example, 4 crashes all with a crash address of 0x0 may just be 4 actual null pointer crashes ; there must be a number of crashes above which there's a fair chance that there would normally be non-null pointer crashes)


I'm not sure how to assess this... maybe if I sampled data from a few months ago?

Comment 5

[Selena Deckelmann :selenamarie :selena]

Attachment: null_crash_counts.txt

Comment 6

[Mike Hommey [:glandium]]

(In reply to Selena Deckelmann :selenamarie :selena from comment #4)
> I'm not sure how to assess this... maybe if I sampled data from a few months
> ago?

Maybe getting crash counts over a longer period?

Looking at the numbers in the attachment, the model/version with the most crashes is Nexus 7/18 (REL), with 13083 crashes. The model/version with the all crashes on a null address with the most crashes is AirTab P970g/15 (REL), with 60 crashes. What chances do we have that those 60 are actually all really crashes on a null address? And the model/version we do know has the problem is very low, with 3 crashes, and that surely isn't enough to say whether all crashes are crashes on a null address.

Comment 7

[Lonnen :lonnen]

You should be able to get this from super search, if this is still desired.

This will get you started:

https://crash-stats.mozilla.com/search/?address=%3D0x0&product=Fennec&_sort=-date&_facets=android_model&_columns=product&_columns=date&_columns=android_model#facet-android_model