Beginning with Sunday afternoon 2015-11-29 https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=c336a29d0318 there has been an intermittent crash with Autophone Talos tpn. There are two distinct signatures: 1. libflashplayer.so + 0x53a038 2. 0x0 Due to the intermittent nature of the crash, I don't think the first occurrence is the regressor. Note that https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=cc0dde3ac2a8 Bug 1206872 - Enable C++ APZ in Fennec nightly builds. r=mfinkle landed Saturday evening 2015-11-28.

Please note : e5e5e5e5e5e5e5e5, fe01fe01fe01fe01 and 3feccccccccccccd

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 libflashplayer.so 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 libflashplayer.so?

We have plans to only install the flash apk for the robocop test which actually tests flash.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #5) > I agree with comment 4. Is there a need to keep libflashplayer.so? 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.

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.

Yes, see bug 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.