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.
Created attachment 101116 [details] Redirect Xvfb stderr output to a subprocess PIPE
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!
(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!
Created attachment 101476 [details] Redirect Xvfb stderr output to /dev/null
Comment on attachment 101476 [details] Redirect Xvfb stderr output to /dev/null Thanks :)
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>
All reviewed patches have been landed. Closing bug.
Very nice!