Filed by: wkocher [at] mozilla.com https://treeherder.mozilla.org/logviewer.html#?job_id=1401266&repo=mozilla-beta http://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-beta-win64-pgo/1470158148/mozilla-beta_win8_64_test_pgo-mochitest-e10s-browser-chrome-7-bm110-tests1-windows-build36.txt.gz
Component: Security: UI → Security: PSM
Priority: -- → P3
Sorry, I don't know why it'd be crashing when loading that URL. Is there a way we can narrow down a regression range for this intermittent starting? I guess we could go through and do a bunch of retriggers on every push before the first instance of this failure until it doesn't fail anymore - is there a way to automate that?
I have tried to automate that, it is difficult- good idea to narrow it down- I think we could find the first instance and retrigger like crazy on linux/win7 20 times each for -10, +5 revisions to see where this started. For the case of windows 7 VM, the tests are not run there by default (only on try)- we are trying to get the tests running there and this bug is occuring much more frequently. :rwood, up for an attempt at bisecting/narrowing down the range?
(In reply to Joel Maher ( :jmaher) from comment #5) > :rwood, up for an attempt at bisecting/narrowing down the range? Absolutely, I'm on it...
Update: In orange factor, it reported the first revision where this intermittent showed up was revision 73a57814a495b29244ef5377e73488a3f3fabb15 on win 8 on 2nd-Aug: https://brasstacks.mozilla.com/orangefactor/index.html?display=Bug&bugid=1291489&entireHistory=true&tree=trunk So I did a bunch of runs on try, on that suspect revision +-3 revisions. Did them on win 7 vm debug because this intermittent happens more frequently on that platform. However, the intermittent actually showed up in each of the revisions: https://firstname.lastname@example.org&fromchange=b0ec72d7e5d7bcf81d2cb452c66304a93ddea2cb&tochange=dfca8e5df69f15247eee2cc2c0f96355f1921212 :jmaher, is this possibly because the patch was introduced but the first win8 build with the patch was done at a later date? How can I narrows this down on win 7 vm? Thanks.
great question- possibly this has always been problematic on win7 vm since we never ran it there. It is possible that if this shows up 1 out of 100 runs, that we need to look up to 100 revisions prior to the first instance. Maybe we could pick revisions from mozilla-central to narrow the day down since we mostly merge once/day into m-c. we could do up to 7 days prior and if that isn't conclusive, then I would say this is an issue we need to debug and look at on win7-vm only.
something odd happened here yesterday, we went from 30 in the last week, to 40 in the last day.
Thanks Joel. Just an update, pushed to try 7 days prior (build broken): https://treeherder.mozilla.org/#/jobs?repo=try&revision=a7fd81554700b311ec6b269b24965817857b8e82 And some revisions from a couple days after that, so far no repro: https://email@example.com&fromchange=e79ca2840e29f6fc7a99bd24f86f7ea4118d1a9b&tochange=1187e5691c59aa64fdbf1944ea0a6afd5e1f4e55 Trying a couple more revisions from august 1st and 2nd: https://firstname.lastname@example.org&fromchange=bbe193d624bdbe7861d3223177a9842da177c24e&tochange=6c865971505f1fca65b0464ac0c05145945e85ee
Reproduced the intermittent on win 7vm with revision 465d150bc8be. https://email@example.com&fromchange=bbe193d624bdbe7861d3223177a9842da177c24e&tochange=6c865971505f1fca65b0464ac0c05145945e85ee&selectedJob=25961727 Will keep trying to narrow it down...
I did a lot of retriggers: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&filter-searchStr=bc7%20e10s%20win%20x64&tochange=5aa02060f7c47a1d4c2c198c18ab7fc59771467b&fromchange=6a6829ccc2b43074b8f3542b3db3213224502eab it looks like this is the culprit: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=53bbfa02d45d :birtles, I see you are the author of this, can you weigh in on why we are getting this failure about 3x more frequently after your patches landed?
Those patches should have no effect on animations that play forwards (and I don't see anything in the test or what it triggers that reverses animations). They also shouldn't have any effect the results of getElementById. I can only suggest that these patches aren't responsible but that there's some race going on here and perhaps these patches happened to tickle something that affected the timing of this test (although they really should have almost zero impact on timing).
Were this going to be something susceptible to retriggering to find a cause, wouldn't you want to start retriggering on beta, given that it was filed from there?
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1272942
You need to log in before you can comment on or make changes to this bug.