Autophone Talos - Intermittent Crash [@0x0] | Crash [@]




Firefox for Android
3 years ago
11 months ago


(Reporter: bc, Unassigned)


({crash, intermittent-failure, regression})

Firefox Tracking Flags

(Not tracked)


(crash signature)


(4 attachments)



3 years ago
Created attachment 8694624 [details]
[@] - tombstone

Beginning with Sunday afternoon 2015-11-29 there has been an intermittent crash with Autophone Talos tpn. There are two distinct signatures:

1. + 0x53a038
2. 0x0

Due to the intermittent nature of the crash, I don't think the first occurrence is the regressor.

Note that 
Bug 1206872 - Enable C++ APZ in Fennec nightly builds. r=mfinkle

landed Saturday evening 2015-11-28.

Comment 1

3 years ago
Created attachment 8694625 [details]
[@] - minidump output

Comment 2

3 years ago
Created attachment 8694628 [details]
[@ 0x0] tombstone

Please note : e5e5e5e5e5e5e5e5, fe01fe01fe01fe01 and 3feccccccccccccd

Comment 3

3 years ago
Created attachment 8694639 [details]
[@ 0x0] minidump output
I strongly suspect the APZ changes are the cause, Having almost 3 weeks of data with <5 total failures for all inbound pushes, then getting 20-30% failures starting the 29th, makes me weary of APZ.  It could be environmental, removing the if we can would be nice :)  I believe APZ makes the painting area larger, this might allow for us to see more of the page than we normally would in tpn which could cause us to load flash elements.
I agree with comment 4. Is there a need to keep

Comment 6

3 years ago
We have plans to only install the flash apk for the robocop test which actually tests flash.
(In reply to Kartikaya Gupta ( from comment #5)
> I agree with comment 4. Is there a need to keep

Yes, we added it because we were missing regressions that affected a large portion of our users
Untracking, as this will be worked around in autophone.
tracking-fennec: ? → ---
I am not clear here- are we going with removing flashplayer by default and only using it for the specific robocop tests that need it?  I could have misread :blassey's post in comment 7.

Comment 10

3 years ago
Yes, see bug 1229807
Depends on: 1229807
So my investigation in bug 1229118 revealed that for tp4m at least we weren't using a displayport before the C++ APZ landed, and that might be the case for autophone as well. If so, then the APZ code will almost definitely increase the displayport and cause things to get painted that weren't getting painted before, and that might trigger flash crashes. I can help diagnose what happened using try builds, if you're able to run the try builds on autophone. However if it turns out to be a result of the larger displayport we should evaluate whether we want to keep the new behaviour (which is more representative of what a user would experience) or artificially truncate the displayport.
Flash is going away (bug 1381916), so there's no point in pursuing this further.
Last Resolved: 11 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.