Bug 64669 – [Gtk] [NRWT] Xvfb produces a lot of stderr output

• Status: RESOLVED
• Resolution: FIXED
• Component: Tools / Tests

[Zan Dobersek]

On Gtk port, when running tests, an Xvfb process is started. It produces a lot of unnecessary stderr output like this:

SCREEN: 0 objects of 176 bytes = 0 total bytes 0 private allocs
DEVICE: 4 objects of 48 bytes = 192 total bytes 0 private allocs
CLIENT: 0 objects of 184 bytes = 0 total bytes 0 private allocs
WINDOW: 0 objects of 48 bytes = 0 total bytes 0 private allocs
PIXMAP: 1 objects of 16 bytes = 16 total bytes 0 private allocs
GC: 0 objects of 56 bytes = 0 total bytes 0 private allocs
CURSOR: 0 objects of 8 bytes = 0 total bytes 0 private allocs
CURSOR_BITS: 0 objects of 8 bytes = 0 total bytes 0 private allocs
DBE_WINDOW: 0 objects of 24 bytes = 0 total bytes 0 private allocs
TOTAL: 5 objects, 208 bytes, 0 allocs
4 DEVICEs still allocated at reset
DEVICE: 4 objects of 48 bytes = 192 total bytes 0 private allocs
CLIENT: 0 objects of 184 bytes = 0 total bytes 0 private allocs
WINDOW: 0 objects of 48 bytes = 0 total bytes 0 private allocs
PIXMAP: 1 objects of 16 bytes = 16 total bytes 0 private allocs
GC: 0 objects of 56 bytes = 0 total bytes 0 private allocs
CURSOR: 0 objects of 8 bytes = 0 total bytes 0 private allocs
CURSOR_BITS: 0 objects of 8 bytes = 0 total bytes 0 private allocs
DBE_WINDOW: 0 objects of 24 bytes = 0 total bytes 0 private allocs
TOTAL: 5 objects, 208 bytes, 0 allocs
1 PIXMAPs still allocated at reset
PIXMAP: 1 objects of 16 bytes = 16 total bytes 0 private allocs
GC: 0 objects of 56 bytes = 0 total bytes 0 private allocs
CURSOR: 0 objects of 8 bytes = 0 total bytes 0 private allocs
CURSOR_BITS: 0 objects of 8 bytes = 0 total bytes 0 private allocs
DBE_WINDOW: 0 objects of 24 bytes = 0 total bytes 0 private allocs
TOTAL: 1 objects, 16 bytes, 0 allocs
[dix] Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list!

Such output will eventually grow when we move onto using multiple workers when testing unless suppressed.

[Zan Dobersek]

Created attachment 101116 [details]
Redirect Xvfb stderr output to a subprocess PIPE

[Philippe Normand]

Comment on attachment 101116 [details]
Redirect Xvfb stderr output to a subprocess PIPE

View in context: https://bugs.webkit.org/attachment.cgi?id=101116&action=review

> Tools/Scripts/webkitpy/layout_tests/port/gtk.py:46
> +        self._xvfb_process = subprocess.Popen(run_xvfb, stderr=subprocess.PIPE)

http://stackoverflow.com/questions/699325/suppress-output-in-python-calls-to-executables

recommends to open /dev/null instead.

Quoting the interesting comment:

"""
If your search engine lead you to this old question (like me), be aware that Manuel's solution (at this time the most valued), namely using PIPE can lead to deadlocks.

Indeed, because pipes are buffered, you can write a certain number of bytes in a pipe, even if no one read it. However the size of buffer is finite. And consequently if your program A has an output larger than the buffer, A will be blocked on writing, while the calling program B awaits the termination of A.
"""

So the preferred solution would be something like:

devnull = open(os.devnull, 'w')
self._xvfb_process = subprocess.Popen(run_xvfb, stderr=devnull)
devnull.close()

Can you please check this would work?
Thanks!

[Zan Dobersek]

(In reply to comment #2)
> 
> devnull = open(os.devnull, 'w')
> self._xvfb_process = subprocess.Popen(run_xvfb, stderr=devnull)
> devnull.close()
> 
> Can you please check this would work?
> Thanks!

This works just as fine, will upload a patch in a moment.
Thanks for the review!

[Zan Dobersek]

Created attachment 101476 [details]
Redirect Xvfb stderr output to /dev/null

[Philippe Normand]

Comment on attachment 101476 [details]
Redirect Xvfb stderr output to /dev/null

Thanks :)

[WebKit Review Bot]

Comment on attachment 101476 [details]
Redirect Xvfb stderr output to /dev/null

Clearing flags on attachment: 101476

Committed r91374: <http://trac.webkit.org/changeset/91374>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Ryosuke Niwa]

Very nice!