<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - Headless mode leaves zombie process" href="https://bugs.documentfoundation.org/show_bug.cgi?id=95843#c12">Comment # 12</a> on <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - Headless mode leaves zombie process" href="https://bugs.documentfoundation.org/show_bug.cgi?id=95843">bug 95843</a> from <a class="email" href="mailto:tcarter@noggin.com.au" title="Travers Carter <tcarter@noggin.com.au>"> Travers Carter</a> <pre>I'm seeing the same behaviour on 5.4.3.2 (Fedora 27) and 5.0.6.2 (CentOS 7.4.1708) It looks to me like the issue here is that fire_glxtest_process() launches a child process to test for GLX regardless of --headless, but reaping the child process is handled by the X display initialisation stuff that only runs when the GLX test passes, which it never does in --headless and there doesn't appear to be a path via which the child is reaped in the --headless case (or possibly any GLX test failure?) I'd guess that either the glxtest child should simply not be launched for --headless but alternatively it probably should be reaped elsewhere for the alternate path(s) The following stack trace (5.4.3.2) shows the non-headless version reaping the glxtest child from X11OpenGLDeviceInfo::GetData() Thread 1 "soffice.bin" hit Breakpoint 5, 0x00007ffff75c5d70 in waitpid () from /lib64/libc.so.6 (gdb) bt #0 0x00007ffff75c5d70 in waitpid () at /lib64/libc.so.6 #1 0x00007fffeff019a0 in X11OpenGLDeviceInfo::GetData() () at /usr/lib64/libreoffice/program/libvcllo.so #2 0x00007fffeff01e90 in X11OpenGLDeviceInfo::X11OpenGLDeviceInfo() () at /usr/lib64/libreoffice/program/libvcllo.so #3 0x00007fffeff0022c in OpenGLHelper::isDeviceBlacklisted() () at /usr/lib64/libreoffice/program/libvcllo.so #4 0x00007fffeff002a4 in OpenGLHelper::supportsVCLOpenGL() () at /usr/lib64/libreoffice/program/libvcllo.so #5 0x00007fffeff00398 in OpenGLHelper::isVCLOpenGLEnabled() () at /usr/lib64/libreoffice/program/libvcllo.so #6 0x00007fffd31d74cd in SalDisplay::BestVisual(_XDisplay*, int, XVisualInfo&) () at /usr/lib64/libreoffice/program/libvclplug_genlo.so #7 0x00007fffd31dc75f in SalDisplay::initScreen(SalX11Screen) const () at /usr/lib64/libreoffice/program/libvclplug_genlo.so #8 0x00007fffd31e22cd in vcl_sal::WMAdaptor::WMAdaptor(SalDisplay*) () at /usr/lib64/libreoffice/program/libvclplug_genlo.so #9 0x00007fffd31e26ab in vcl_sal::NetWMAdaptor::NetWMAdaptor(SalDisplay*) () at /usr/lib64/libreoffice/program/libvclplug_genlo.so #10 0x00007fffd31e3571 in vcl_sal::WMAdaptor::createWMAdaptor(SalDisplay*) () at /usr/lib64/libreoffice/program/libvclplug_genlo.so #11 0x00007fffd31ddf3d in SalDisplay::Init() () at /usr/lib64/libreoffice/program/libvclplug_genlo.so #12 0x00007fffd31de0e4 in SalX11Display::SalX11Display(_XDisplay*) () at /usr/lib64/libreoffice/program/libvclplug_genlo.so #13 0x00007fffd60cec5e in SalKDEDisplay::SalKDEDisplay(_XDisplay*) () at /usr/lib64/libreoffice/program/libvclplug_kde4lo.so #14 0x00007fffd60d3d26 in KDESalInstance::CreateDisplay() const () at /usr/lib64/libreoffice/program/libvclplug_kde4lo.so #15 0x00007fffd31de7c2 in X11SalInstance::AfterAppInit() () at /usr/lib64/libreoffice/program/libvclplug_genlo.so #16 0x00007fffefdf89e2 in InitVCL() () at /usr/lib64/libreoffice/program/libvcllo.so #17 0x00007fffefdfa00d in ImplSVMain() () at /usr/lib64/libreoffice/program/libvcllo.so #18 0x00007fffefdfa070 in SVMain() () at /usr/lib64/libreoffice/program/libvcllo.so #19 0x00007ffff791d515 in soffice_main () at /usr/lib64/libreoffice/program/libsofficeapp.so #20 0x000055555555478b in main ()</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>