Bug 111167 – REGRESSION(r144422): Caused over 20 tests to fail assertion on Chromium Win port as ASSERTION FAILED: m_platformRequestUpdated (Requested by toyoshim on #webkit).

• Component: New Bugs
• Status: RESOLVED FIXED

[WebKit Review Bot]

http://trac.webkit.org/changeset/144422 broke the build:
Caused over 20 tests to fail assertion on Chromium Win port as ASSERTION FAILED: m_platformRequestUpdated (Requested by toyoshim on #webkit).

This is an automatic bug report generated by the sheriff-bot. If this bug
report was created because of a flaky test, please file a bug for the flaky
test (if we don't already have one on file) and dup this bug against that bug
so that we can track how often these flaky tests case pain.

"Only you can prevent forest fires." -- Smokey the Bear

[WebKit Review Bot]

Created attachment 190940 [details]
ROLLOUT of r144422

Any committer can land this patch automatically by marking it commit-queue+.  The commit-queue will build and test the patch before landing to ensure that the rollout will be successful.  This process takes approximately 15 minutes.

If you would like to land the rollout faster, you can use the following command:

  webkit-patch land-attachment ATTACHMENT_ID

where ATTACHMENT_ID is the ID of this attachment.

[Takashi Toyoshima]

fyi: crash dump example

crash log for DumpRenderTree (pid 3228):
STDOUT: <empty>
STDERR: ASSERTION FAILED: m_platformRequestUpdated
STDERR: Backtrace:
STDERR: 	WebKit::WebFilterOperation::WebFilterOperation [0x671BE055+10570069]
STDERR: 	WebKit::WebFilterOperation::WebFilterOperation [0x671BC7C8+10563784]
STDERR: 	WebKit::WebSharedGraphicsContext3D::createCompositorThreadContext [0x6632045A+764717]
STDERR: 	WebKit::WebFilterOperation::WebFilterOperation [0x67919275+18283381]
STDERR: 	WebKit::WebFilterOperation::WebFilterOperation [0x67395C36+12502326]
STDERR: 	WebKit::WebFilterOperation::WebFilterOperation [0x673957BE+12501182]
STDERR: 	WebKit::WebFilterOperation::WebFilterOperation [0x67395047+12499271]
STDERR: 	WebKit::WebSharedGraphicsContext3D::createCompositorThreadContext [0x663D8D20+1520627]
STDERR: 	(No symbol) [0x01210CEA]
STDERR: 	(No symbol) [0x01204DB7]
STDERR: 	(No symbol) [0x01203F1F]
STDERR: 	(No symbol) [0x0120D798]
STDERR: 	(No symbol) [0x01217D21]
STDERR: 	(No symbol) [0x012175EE]
STDERR: 	(No symbol) [0x0120050F]
STDERR: 	(No symbol) [0x011FF39F]
STDERR: 	(No symbol) [0x013605AF]
STDERR: 	(No symbol) [0x013603DF]
STDERR: 	BaseThreadInitThunk [0x7547339A+18]
STDERR: 	RtlInitializeExceptionChain [0x77C69EF2+99]
STDERR: 	RtlInitializeExceptionChain [0x77C69EC5+54]

[WebKit Review Bot]

Comment on attachment 190940 [details]
ROLLOUT of r144422

Clearing flags on attachment: 190940

Committed r144446: <http://trac.webkit.org/changeset/144446>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Alexey Proskuryakov]

This rollout appears extremely confused. There is no PlatformRequest anywhere in WebFilterOperation, and r144422 is very unlikely to have caused this assertion anywhere.

Please do some research before rolling out patches. It is not OK to undo other people's work without even looking.

[Eric Seidel (no email)]

(In reply to comment #5)
> This rollout appears extremely confused. There is no PlatformRequest anywhere in WebFilterOperation, and r144422 is very unlikely to have caused this assertion anywhere.
> 
> Please do some research before rolling out patches. It is not OK to undo other people's work without even looking.

Please be pleasant to your fellow webkit contributors.

[Alexey Proskuryakov]

Eric, I'm not sure why you are making it personal.

[Adam Barth]

The builders in question are located at:

http://build.chromium.org/p/chromium.webkit/waterfall?show=WebKit%20Win7%20(dbg)(1)
http://build.chromium.org/p/chromium.webkit/waterfall?show=WebKit%20Win7%20(dbg)(2)

[Takashi Toyoshima]

Hi Alexey,

I'm sorry if my revert  was wrong. I ping you at #webkit, but it's 5am in PST. Anyway, I should describe more details here before I rolled out.

Many tests started to crash around your change, and all of them fired this assertion failure in WebFilterOperation. Yours was only patch to touch FilterOperation in my candidate list. So I decided to roll out your change. I could not verify if this rolling out was right because it was also midnight in my timezone, but I shared this information with the next PST gardener.

Gardening is difficult mission which should be done under strong time pressure. WebKit contains many components and it is so complicated that one person can not understand whole WebKit. Please forgive mistakes.

[Alexey Proskuryakov]

Yes, my patch touched FilterOperation, but not WebFilterOperation. WebFilterOperation files do not even include FilterOperation.h.

I was certainly more harsh than I could have been, but please understand that this was a large patch that took a lot of effort in making. I spent several afternoons of my own time (as it was a non-work side project) fixing the build on various platforms. Seeing this work undone with a single mouse click because a builder I didn't even know existed was seeing assertion failures in a file that I did not touch was very annoying.

Something I'd like people to better understand about gardening is that rolling out patches is very easy to do, but is a strong measure. A bona fide effort in addressing issues another way should be taken first.

[James Robinson]

(In reply to comment #2)
> fyi: crash dump example
> 
> crash log for DumpRenderTree (pid 3228):
> STDOUT: <empty>
> STDERR: ASSERTION FAILED: m_platformRequestUpdated
> STDERR: Backtrace:
> STDERR:     WebKit::WebFilterOperation::WebFilterOperation [0x671BE055+10570069]
> STDERR:     WebKit::WebFilterOperation::WebFilterOperation [0x671BC7C8+10563784]
> STDERR:     WebKit::WebSharedGraphicsContext3D::createCompositorThreadContext [0x6632045A+764717]
> STDERR:     WebKit::WebFilterOperation::WebFilterOperation [0x67919275+18283381]
> STDERR:     WebKit::WebFilterOperation::WebFilterOperation [0x67395C36+12502326]
> STDERR:     WebKit::WebFilterOperation::WebFilterOperation [0x673957BE+12501182]
> STDERR:     WebKit::WebFilterOperation::WebFilterOperation [0x67395047+12499271]
> STDERR:     WebKit::WebSharedGraphicsContext3D::createCompositorThreadContext [0x663D8D20+1520627]
> STDERR:     (No symbol) [0x01210CEA]
> STDERR:     (No symbol) [0x01204DB7]
> STDERR:     (No symbol) [0x01203F1F]
> STDERR:     (No symbol) [0x0120D798]
> STDERR:     (No symbol) [0x01217D21]
> STDERR:     (No symbol) [0x012175EE]
> STDERR:     (No symbol) [0x0120050F]
> STDERR:     (No symbol) [0x011FF39F]
> STDERR:     (No symbol) [0x013605AF]
> STDERR:     (No symbol) [0x013603DF]
> STDERR:     BaseThreadInitThunk [0x7547339A+18]
> STDERR:     RtlInitializeExceptionChain [0x77C69EF2+99]
> STDERR:     RtlInitializeExceptionChain [0x77C69EC5+54]

This stack symbolized incorrectly - this has nothing to do with WebFilterOperation or FilterOperation.  That said, the patch in question definitely did break the port.

[Alexey Proskuryakov]

Is there a way to get a correct stack trace? I do not have a functional Windows machine.

[James Robinson]

I don't see any properly symbolized stacks on the bots, although perhaps there are some I can't find.  It appears that every single test crashes, if that's useful.

[Alexey Proskuryakov]

OK, thank you for looking!