CCLayerTreeHostImplTest.testRemoveRenderPasses fails on Chromium Linux build. Probably caused by: http://trac.webkit.org/changeset/122525 See: http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Linux%2032/builds/20930
Skipped: http://trac.webkit.org/changeset/122576
A better bot backtrace: base::debug::StackTrace::StackTrace() [0x7fc4cb993592] base::(anonymous namespace)::StackDumpSignalHandler() [0x7fc4cb9f85a5] 0x7fc4c4929af0 WTF::OwnPtr<>::operator->() [0x7fc4cde270a0] (anonymous namespace)::configureRenderPassTestData() [0x7fc4cde1644d] (anonymous namespace)::CCLayerTreeHostImplTest_testRemoveRenderPasses_Test::TestBody() [0x7fc4cde16abc]
Created attachment 152270 [details] Patch The test won't crash for me locally. >_< From examing the code, this is the only iffy thing I can see. Do you think it would be a good condidate to fix the problem, enne?
(In reply to comment #3) > Created an attachment (id=152270) [details] > Patch > > The test won't crash for me locally. >_< > > From examing the code, this is the only iffy thing I can see. Do you think it would be a good condidate to fix the problem, enne? That really doesn't look like it should be null. Is this a debug vs. release issue? Does a try job crash for you, and can you try the patch there?
Idk what's up with the trybots but I am unable to apply this change. Even if I remove everything except the "fix". It seems like the trybots are maybe sitting at some version prior to the breaking even occuring. Either way, I think this change is needed, as it is valid for the compiler to release() the pointer before we deref it for the id().
Comment on attachment 152270 [details] Patch R=me. I can buy that argument that renderPass could be null here if the args are evaluated right-to-left. Let's give this a try. Please watch the bots when you land this.
Committed r122602: <http://trac.webkit.org/changeset/122602>
Looks like the bots went green :D