1016081 - B2G emulator reftest bustage when merging b-i and m-c

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Andrew Halberstadt [:ahal]]

Several b2g emulator reftests started failing when b-i was merged to m-c. On b-i, the same failures only happened when m-c was merged to b-i. So it seems like it might be two changes interacting with each other.

https://tbpl.mozilla.org/?rev=545c35907eff

Comment 1

[Kartikaya Gupta (email:[e-mail])]

The b-i regression range is:

http://hg.mozilla.org/integration/b2g-inbound/pushloghtml?fromchange=e08f8d3af303&tochange=b11c3c75dda1

The m-c regression range is:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ca41feb4523e&tochange=545c35907eff

The m-i regression range is:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=fd13d0871449&tochange=76f83b6745f1

All of these are largely composed of merge csets, which means this is most likely an interaction between two changes that landed on different trees - one on m-i and one on b-i.

Comment 2

[Andrew Halberstadt [:ahal]]

This try run disables the oop patch, which is likely one of the conflicting changesets:
https://tbpl.mozilla.org/?tree=Try&rev=16150765c224

Comment 3

[Kartikaya Gupta (email:[e-mail])]

I'm going to try bisecting through the merge csets by pushing to try.

First bisection: merge of d85a5aa53fd2 and ca41feb4523e: https://tbpl.mozilla.org/?tree=Try&rev=91e94dda215c

Second bisection: merge of e08f8d3af303 and 21d0c653afa1: https://tbpl.mozilla.org/?tree=Try&rev=2a14fcd9e444 (included a conflict resolve)

Comment 4

[Kartikaya Gupta (email:[e-mail])]

Third bisection: merge of e08f8d3af303 and 5e1bd5190442: https://tbpl.mozilla.org/?tree=Try&rev=866e11df3666 (also same conflict resolve)

Comment 5

[Andrew Halberstadt [:ahal]]

Thanks, if it turns out it is the oop patch, I would really like to know what the other changeset involved is so I at least have a chance at fixing the problem before disabling tests and re-landing.

Comment 6

[Kartikaya Gupta (email:[e-mail])]

Based on staring at the regression ranges and whatnot, I strongly suspect that Andrew's try push in comment 2 will go green. If it does, we should land that patch on m-c and merge it to m-i and b-i, opening the trees as they go green (and assuming there are no other failures).

I also think the narrowest range we have so far for the inbound change that interfered is https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b873c10c208d&tochange=6c53f6dbb7d0

Assuming this is the case, my "first bisection" above is probably a waste, but the second and third bisections should help narrow down the inbound range using 21d0c653afa1 and 5e1bd5190442 as the bisection points.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

Also pushed a fourth bisection: merge of e08f8d3af303 and ce90f049d620: https://tbpl.mozilla.org/?tree=Try&rev=dba7643d2fd6 to get a little better coverage on that inbound range.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

Well. Andrew's backout still has some consistent oranges, although they're different from what's on m-c. I don't know if we should land the backout or not.

My "second bisection" still has the reftest failures, which means we have narrowed down the inbound range to https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b873c10c208d&tochange=21d0c653afa1

Comment 9

[Kartikaya Gupta (email:[e-mail])]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #8)
> Well. Andrew's backout still has some consistent oranges, although they're
> different from what's on m-c. I don't know if we should land the backout or
> not.

So it looks like the failures here are things that were marked as fails-if(B2G) prior to cset f05fbe6261ac and changed to random-if(B2G&&browserIsRemote) in that cset. So obviously they're going to fail.

I think it makes sense to back out csets c4eebcb1c390, f05fbe6261ac, and 6ae6efd7f5e6 which should restore greenness. I have a try push going with this backout at https://tbpl.mozilla.org/?tree=Try&rev=d1592e9d2d26 although if we don't want to wait a few more hours then we can just land it on central. I'm pretty sure it'll be green.

Meanwhile we continue bisecting inbound changes through try to find the other change that interfered with the oop-enabling.

Comment 10

[Kartikaya Gupta (email:[e-mail])]

Bisection one is green, bisection three is orange. This further narrows the range to: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b873c10c208d&tochange=5e1bd5190442

Frankly in that range my changes to enable low-res and progressive painting look pretty likely. I pushed a backout of those changes to try as well: https://tbpl.mozilla.org/?tree=Try&rev=ea2070ef09f0

Comment 11

[Phil Ringnalda (:philor)]

Backed out bug 897996 in https://hg.mozilla.org/mozilla-central/rev/962f3203939f and bug 994293 in https://hg.mozilla.org/mozilla-central/rev/cbe4f69c2e9c, and skipped the newly-added XUL reftest that was failing in R15 in https://hg.mozilla.org/mozilla-central/rev/b36a923d9b4a.

Comment 12

[Kartikaya Gupta (email:[e-mail])]

Thanks for landing the backout, philor!