1296899 - Deadlock between SendGetCookieString() and SendFlushRendering()

Status: RESOLVED WORKSFORME

(Core :: IPC, defect)

Description

[Brad Lassey [:blassey] (use needinfo?)]

Just saw this deadlock and got a sample of the chrome and content processes before force killing it.

Comment 1

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Do you have stacks? Both of these messages are supposed to be sent from content to chrome, so I don't understand how that could happen.

Comment 2

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: Sample of Nightly deadlock.txt

Comment 3

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: Sample of Nightly Web Content deadlock.txt

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

OK, I see. The content process is waiting on the chrome process. The chrome main thread is waiting on the compositor thread. Not sure what the compositor thread is doing, but it looks like something significant. David, have you seen anything like this recently?

Comment 5

[David Anderson [:dvander] - inactive, e-mail if emergency]

That does look significant, but it's surprising it would block that long. I've never seen composites on GL or D3D take more than a few ms. If it happens again I'd be curious if we return out of that UseTiles call.

ni?ing Markus in case he's seen this on Mac before. Maybe it's something weird with IOSurfaces.

Comment 6

[Markus Stange [:mstange]]

The compositor is doing texture upload. We know that the way we're doing texture upload is really slow on Mac, but it's not supposed to be *that* slow... It could be that we were just trying to upload tons and tons of stuff. If you set the pref gfx.logging.painted-pixel-count.enabled to true, we print the number of pixels to the console, but I'm not sure whether having that information would have helped here.

IOSurface does not seem to be involved.