Description: Under Linux/X11 (tested in CentOS 8) when using a 16 bit color Xserver (also called TrueColor): All versions NEWER than 6.3.6(.2) show UI bitmap corruption and then will crash when any document creation operation is performed. This is a problem for my environment because we use lots of thin clients and 24 bit color creates 33% more network activity than 16 bit color. Have no problems with any other programs in 16 bit color (including latest Firefox and recent GIMP). Steps to Reproduce: Install LO version newer than 6.3, set display to 16 bit color, launch LO. Actual Results: bitmap corruption/crash Expected Results: no corruption/crashes Reproducible: Always User Profile Reset: Yes Additional Info: Can't paste help-> about. Any menu selections cause LO to crash. Crash report uploaded crashreport.libreoffice.org/stats/crash_details/88876691-8c91-4d6a-a34f-27e12da2cf5a
Created attachment 164178 [details] Corruption of UI bitmaps in 16 bit color
Thank you for reporting the bug. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Yes, it affects every version, starting with 6.4.0 and including 7.0.0. In 7.0.0 it is so bad that it crashes immediately after the initial windows are drawn.
Sorry, I should clarify that because we are using thin clients, I am NOT using the console (a locally-connected Xserver). LO is running on a server and displaying, through X11, on remote 16-bit-display machines. Anyone can simulate this by using ssh. I will follow up with some additional testing, soon, to try and see if it can be narrowed down any more.
OK, I have key information after hours of trying things. The problem only exists if you are using the "generic" VCL (LibreOffice's built-in theme/UI) with 16 bit color with LO > 6.3. Using the generic VCL occurs if you don't install the gnome-integration package (which is an optional package), OR if you use export SAL_USE_VCLPLUGIN="gen" before launching LO to force the generic VCL. This is probably why I have not seen any other reports of this issue- it is rare, but will bite certain users (and my users fall in that category). You might ask "why not just use gtk3 VCL?" Well, we can, but it is MUCH slower running remotely/thin client with scrolling, menus, and selecting text, and certain other operations. For example, selecting text is at least 500% slower, and very noticeable/annoying, even at 100Mb/s. So, to replicate this problem: 1) Install/prep LibreOffice 6.4.0 or newer. 2) Change your Xserver to 16 bit TrueColor. 3) Launch LO with export SAL_USE_VCLPLUGIN="gen" ; $INSTALLPATH/program/soffice -OR- 3) Remove the LO gnome-integration package and launch LO.
I testing this using LO 7.0.0.3 under Linux Mint 19.3, while forcing 16 bit color and specify generic vcl, but I can't even get to the main menu. LO crashes on launch, shows a Document Recovery dialog with no documents in it, and a Crash Report dialog. As soon as I close the Document Recovery dialog, the program crashes again, showing the same two dialogs. It'll do this over and over forever, unless the application is manually killed. Also, the Document Recovery dialog has focus, with no way to actually interact with the Crash Recovery dialog to send a crash report. I haven't reported any bugs in a while, so I will only confirm. But according to the old bug prioritization flowchart, a crash on startup that affects a clean install would suggest an importance of at least medium critical, since it might not affect that many users?
It has been 1.5 years since I reported this. I am just posting to let anyone reading know it is still a big issue for us and it is keeping us trapped on older versions. Thanks
(In reply to tmacalp from comment #6) > ... > I haven't reported any bugs in a while, so I will only confirm. But > according to the old bug prioritization flowchart, a crash on startup that > affects a clean install would suggest an importance of at least medium > critical, since it might not affect that many users? IMHO letting the priority/importance as it is is ok since it's a corner case 16 bit depth color. I searched a bit how to have 16 bit color but /etc/X11/xorg.conf.d/ is empty for me (I'm on pc Debian testing x86-64 updated today). So I wouldn't like to copy paste a manual config found on the net which may damage my monitor.
Would now be nice to get a bibisect of the bug - https://wiki.documentfoundation.org/QA/HowToBibisect Please could you do it?