STR: 1. Take any EXPECT_CALL statement in a gtest, like this one [1], and alter the expected call count (e.g. from 0 to 1). 2. Run the gtest with |mach gtest|. Expected results: The test fails as a result of the mismatch. Actual results: The test run does output a message about the mismatch: /home/botond/dev/projects/mozilla/central/gfx/layers/apz/test/gtest/TestTreeManager.cpp:94: Failure Actual function call count doesn't match EXPECT_CALL(*mcc, HandleTap(TapType::eLongTap, _, _, _, _))... Expected: to be called 1 times Actual: never called - unsatisfied and active but the test still passes. The EXPECT_CALL statements are only useful for catching regressions if they actually cause the test to fail, so this should be fixed. [1] http://searchfox.org/mozilla-central/rev/8b70b0a5038ef9472fe7c53e04a70c978bb06aed/gfx/layers/apz/test/gtest/TestTreeManager.cpp#94

It might be worth trying to bisect this to figure out when it started happening. Although that involves doing local builds so perhaps using the Toronto icecc cluster would be good. In theory it should be able to run unattended using `git bisect` although I suspect if you go back far enough compilation might break because of system dependencies.

Just for kicks I did a build just before bug 1343557 landed and it still had the same problem.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #1) > It might be worth trying to bisect this to figure out when it started > happening. Although that involves doing local builds so perhaps using the > Toronto icecc cluster would be good. I did the suggested bisection, and found that this is the regressing commit: https://hg.mozilla.org/integration/mozilla-inbound/rev/0151fc9f97a2 It's not exactly clear to me _how_ that commit could have changed the behaviour...

Interesting. It must be somehow a result of the `tm->ClearTree();` call that I added to TearDown()? Maybe it's causing the GeckoContentController to get destroyed before the end of the test, and so unsatisfied calls are thrown away or made non-fatal or something?

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #4) > Interesting. It must be somehow a result of the `tm->ClearTree();` call that > I added to TearDown()? Maybe it's causing the GeckoContentController to get > destroyed before the end of the test, and so unsatisfied calls are thrown > away or made non-fatal or something? But that call was added to APZCBasicTester::TearDown(), while EXPECT_CALL statements in e.g. APZCTreeManagerTester are affected as well...

Commenting out the part of the patch that creates the CheckerboardFlushObserver, and the extra reference to the APZCTreeManager to live in the task that cleares the flush observer, fixes the bug, suggesting that the issue is related to the APZCTM's lifetime being extended.

I'll investigate, since it's a regression from my patch.

Anyways, the issue is specific to APZ GTests.

Whoops, didn't see your comment 6. If you get to the bottom of it that's great, otherwise I'll look into it tomorrow.

(In reply to Botond Ballo [:botond] from comment #6) > Commenting out the part of the patch that creates the > CheckerboardFlushObserver, and the extra reference to the APZCTreeManager to > live in the task that cleares the flush observer, fixes the bug, suggesting > that the issue is related to the APZCTM's lifetime being extended. My theory is: - Extending the lifetime of the APZCTM extends the lifetime of the GeckoCC - It's the destructor of the GeckoCC (specific the MockCC) that performs the EXPECT_CALL checks - We are delaying when that destructor runs past the time when the test harness checks for and reports failures

^ This patch, which clears the MockCC in TearDown(), fixes the issue, confirming my theory. It would be nice to add a test that would catch if this regressed again, by checking that an EXPECT_CALL failure really does fail the test, but I'm not sure how to do that.

Try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=fcc64ed4b23641dd1c66ad5cb94c4a280aa9bc35

Comment on attachment 8865684 [details] Bug 1362889 - Ensure the MockContentController in APZ GTests doesn't outlive the test fixture. https://reviewboard.mozilla.org/r/137316/#review140328 Thanks!

Pushed by bballo@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/1a4891c3d86a Ensure the MockContentController in APZ GTests doesn't outlive the test fixture. r=kats