https://bugs.documentfoundation.org/show_bug.cgi?id=101822
Bug ID: 101822
Summary: glxtest zombie process on all non-Gtk+ X11 VCL
platforms
Product: LibreOffice
Version: 5.0.6.3 release
Hardware: All
OS: Linux (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: graphics stack
Assignee: [email protected]
Reporter: [email protected]
Since working on our 5.0 release I've noticed a zombie process spawned from LO.
sberg pointed me to glxtest, which I could verify to be the culprit.
The original problem is OpenGLHelper::isVCLOpenGLEnabled(), which calls
officecfg::Office::Common::VCL::ForceOpenGL::get(), which throws an exception
in comphelper::getProcessServiceFactory(), which is caught somewhere down the
stack, and now can't cleanup the Zombie and misses some of the OpenGL stuff.
Actually I'm amazed that LO still manages to run with an unexpected exception
in the OpenGL code :-)
I could verify that this problem happens with all non-Gtk+ based X11 VCL
plugins (kde4, gen, tde).
In the end I did two debug runs with backtrace breakpoints for Gtk+ and KDE4
(AKA break with command ; bt ; c ; end).
This pointed to the commit "wait until we know the UI language before
initializing gtk" -
http://cgit.freedesktop.org/libreoffice/core/commit/?id=d07e7d692ddd2a9ab956a59bcc0f676c7d76bc10
At this point application initialization was split, with the Gtk+ i18n stuff
depending on it.
>From the attached debug logs:
#15 0x00002aaab118a514 in CreateSalInstance() () at
/home/glg/Development/libreoffice/symbols/vcl/unx/generic/plugadapt/salplug.cxx:240
#16 0x00002aaab1107780 in InitVCL() () at
/home/glg/Development/libreoffice/symbols/vcl/source/app/svmain.cxx:290
and
#14 0x00002aaac40a122b in GtkInstance::AfterAppInit() (this=0x754c50) at
/home/glg/Development/libreoffice/symbols/vcl/unx/gtk/gtkinst.cxx:175
#15 0x00002aaab11078a8 in InitVCL() () at
/home/glg/Development/libreoffice/symbols/vcl/source/app/svmain.cxx:304
So Gtk+ now delays some initialization, especially the problematic
SalDisplay::Init() to AfterAppInit(). I guess it's not the origin of the
problem, but something else silently depended on the move. Not sure if it's
easier to move the SalDisplay::Init() based init to AfterAppInit() in all other
VCL plugins, especially if I see the sprinkling of EnsureInit() everywhere in
Gtk+ :-(
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
