Bug 64669 - [Gtk] [NRWT] Xvfb produces a lot of stderr output
Summary: [Gtk] [NRWT] Xvfb produces a lot of stderr output
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-17 06:30 PDT by Zan Dobersek
Modified: 2011-07-20 09:52 PDT (History)
2 users (show)

See Also:


Attachments
Redirect Xvfb stderr output to a subprocess PIPE (1.56 KB, patch)
2011-07-17 06:45 PDT, Zan Dobersek
no flags Details | Formatted Diff | Diff
Redirect Xvfb stderr output to /dev/null (1.63 KB, patch)
2011-07-20 08:47 PDT, Zan Dobersek
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Zan Dobersek 2011-07-17 06:30:17 PDT
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.
Comment 1 Zan Dobersek 2011-07-17 06:45:34 PDT
Created attachment 101116 [details]
Redirect Xvfb stderr output to a subprocess PIPE
Comment 2 Philippe Normand 2011-07-18 14:14:42 PDT
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!
Comment 3 Zan Dobersek 2011-07-20 08:46:31 PDT
(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!
Comment 4 Zan Dobersek 2011-07-20 08:47:51 PDT
Created attachment 101476 [details]
Redirect Xvfb stderr output to /dev/null
Comment 5 Philippe Normand 2011-07-20 08:54:32 PDT
Comment on attachment 101476 [details]
Redirect Xvfb stderr output to /dev/null

Thanks :)
Comment 6 WebKit Review Bot 2011-07-20 09:33:41 PDT
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>
Comment 7 WebKit Review Bot 2011-07-20 09:33:47 PDT
All reviewed patches have been landed.  Closing bug.
Comment 8 Ryosuke Niwa 2011-07-20 09:52:29 PDT
Very nice!