1008188 - With low-precision buffer, layers dumping, and paint dumping enabled, the content process sometimes deadlocks

Status: RESOLVED WORKSFORME

(Core :: Graphics: Layers, defect)

Description

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

Attachment: Backtrace of deadlock

I have a local patch queue that enables low-precision buffer and progressive painting on B2G (see bug 993473 and dependencies). With this patch queue applied I sometimes run into a deadlock. This happens particularly when I also enable the layers.dump pref - I'm not sure why but maybe just timing. When the deadlock occurs, the root process continues operating and I can scroll to previously painted areas but nothing new gets painted.

I was able to attach gdb and found that the gecko thread of the child process is stuck in a lock and never comes unstuck. Backtrace attached.

Comment 1

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

Actually it's not really a deadlock. The perform_lock_unlock_operation call makes an ioctl call that never returns. Even though the genlock_lock object passed in has a timeout of "1000", it looks like maybe the timeout is never respected? I can see the code in gdb all the way down the callstack to the ioctl assembly in bionic, so maybe this is a kernel or driver bug?

Comment 2

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

I seem to be able reproduce this pretty easily with layers.dump set to true, and haven't run into it yet with that set to false. I wonder if it's more than just timing - does the layer dumping code fiddle with these locks?

Comment 3

[Benoit Jacob [:bjacob] (mostly away)]

If the layers dumping code tries to grab the pixels from textures, then yes. Anything that wants to access pixels in a gralloc buffer, has to lock.

Comment 4

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

BenWa suggested this might be because of the B2G_DUMP_PAINTING=1 that I have in my .userconfig. I'll disable that and see if it still happens.

Comment 5

[Chris Lord [:cwiiis]]

If you're not interested in the image content, I'd suggest using the MOZ_DUMP_PAINT_LIST environment variable rather than B2G_DUMP_PAINTING - the former won't output image content, so doesn't have as large an effect on behaviour/performance.

Comment 6

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

Removing the B2G_DUMP_PAINTING makes this go away. I still think this is a bug somewhere, but not urgent I guess.

Comment 7

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

(In reply to Chris Lord [:cwiiis] from comment #5)
> If you're not interested in the image content, I'd suggest using the
> MOZ_DUMP_PAINT_LIST environment variable rather than B2G_DUMP_PAINTING - the
> former won't output image content, so doesn't have as large an effect on
> behaviour/performance.

The reason I had B2G_DUMP_PAINTING in my user config (as I just re-discovered) is that all the display-list dumping code is #ifdef'd so that it only exists if MOZ_DUMP_PAINTING is defined. So it's basically impossible to have both display-list dumping and layers dumping enabled because of this bug.

Comment 8

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

Seems like MOZ_DUMP_PAINTING with layers dumping is just busted in general. Maybe we should kill that code unless somebody can fix it?

Comment 9

[Chris Lord [:cwiiis]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #7)
> (In reply to Chris Lord [:cwiiis] from comment #5)
> > If you're not interested in the image content, I'd suggest using the
> > MOZ_DUMP_PAINT_LIST environment variable rather than B2G_DUMP_PAINTING - the
> > former won't output image content, so doesn't have as large an effect on
> > behaviour/performance.
> 
> The reason I had B2G_DUMP_PAINTING in my user config (as I just
> re-discovered) is that all the display-list dumping code is #ifdef'd so that
> it only exists if MOZ_DUMP_PAINTING is defined. So it's basically impossible
> to have both display-list dumping and layers dumping enabled because of this
> bug.

I think there are ways you can pass extra stuff to the configure (in which case you can pass --enable-paint-dumping, or whatever it is), but you can also use edit-prefs.sh and disable layers.dump (note, this will be re-enabled each time you flash Gaia I think)

It would be nice to fix this code of course, just offering work-arounds in case it helps.

Comment 10

[Benoit Girard (:BenWa)]

FWIW I always build b2g with just 'export B2G_DUMP_PAINTING=1' and will often have both layers and display list dumping enable and never hit any deadlock on the flame.

Comment 11

[Gregory Pappas [:gregp]]

Unable to reproduce