Download it now!
Bug 126272 - Application Error with invalid SAL_USE_VCLPLUGIN values
Summary: Application Error with invalid SAL_USE_VCLPLUGIN values
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.2.5.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 126351 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-07-07 19:17 UTC by Max A. Dednev
Modified: 2019-10-11 16:23 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
ld log file for libreoffice 6.2.5 (8.39 MB, application/x-xz)
2019-07-07 19:53 UTC, Max A. Dednev
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Max A. Dednev 2019-07-07 19:17:31 UTC
This bug was filed from the crash reporting server and is br-abd13333-8a0e-48f9-acc1-7feb0d372319.
=========================================

After running libreoffice6.2 in Debian 9.9 with latest updates I receive message:
Application Error

gdb shows following backtrace:

[makc@verstak tmp]$ gdb --args /opt/libreoffice6.2/program/soffice.bin                      
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /opt/libreoffice6.2/program/soffice.bin...(no debugging symbols found)...done.
(gdb) r
Starting program: /opt/libreoffice6.2/program/soffice.bin 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffd684a700 (LWP 5744)]
[New Thread 0x7fffd6049700 (LWP 5745)]

Thread 1 "soffice.bin" received signal SIGSEGV, Segmentation fault.
0x00007ffff7de4c7c in elf_machine_rela (skip_ifunc=0, reloc_addr_arg=0x7fffe1290ff8, version=0x30, sym=0x7fffe1090300, reloc=0x7fffe10905d0, map=0x6d8d90) at ../sysdeps/x86_64/dl-machine.h:307
307     ../sysdeps/x86_64/dl-machine.h: Нет такого файла или каталога.
(gdb) bt
#0  0x00007ffff7de4c7c in elf_machine_rela (skip_ifunc=0, reloc_addr_arg=0x7fffe1290ff8, version=0x30, sym=0x7fffe1090300, reloc=0x7fffe10905d0, map=0x6d8d90) at ../sysdeps/x86_64/dl-machine.h:307
#1  elf_dynamic_do_Rela (skip_ifunc=0, lazy=<optimized out>, nrelative=<optimized out>, relsize=<optimized out>, reladdr=<optimized out>, map=0x6d8d90) at do-rel.h:137
#2  _dl_relocate_object (scope=<optimized out>, reloc_mode=reloc_mode@entry=1, consider_profiling=<optimized out>, consider_profiling@entry=0) at dl-reloc.c:259
#3  0x00007ffff7decde1 in dl_open_worker (a=a@entry=0x7fffffffc140) at dl-open.c:435
#4  0x00007ffff7de8644 in _dl_catch_error (objname=objname@entry=0x7fffffffc130, errstring=errstring@entry=0x7fffffffc138, mallocedp=mallocedp@entry=0x7fffffffc12f, 
    operate=operate@entry=0x7ffff7deca70 <dl_open_worker>, args=args@entry=0x7fffffffc140) at dl-error.c:187
#5  0x00007ffff7dec609 in _dl_open (file=0x7fffffffc3b0 "libnss_files.so.2", mode=-2147483647, caller_dlopen=0x7ffff350330e <nss_load_library+238>, nsid=-2, argc=<optimized out>, argv=<optimized out>, 
    env=0x6d18f0) at dl-open.c:660
#6  0x00007ffff351a31d in do_dlopen (ptr=ptr@entry=0x7fffffffc380) at dl-libc.c:87
#7  0x00007ffff7de8644 in _dl_catch_error (objname=0x7fffffffc360, errstring=0x7fffffffc368, mallocedp=0x7fffffffc35f, operate=0x7ffff351a2e0 <do_dlopen>, args=0x7fffffffc380) at dl-error.c:187
#8  0x00007ffff351a3af in dlerror_run (operate=operate@entry=0x7ffff351a2e0 <do_dlopen>, args=args@entry=0x7fffffffc380) at dl-libc.c:46
#9  0x00007ffff351a422 in __GI___libc_dlopen_mode (name=name@entry=0x7fffffffc3b0 "libnss_files.so.2", mode=mode@entry=-2147483647) at dl-libc.c:163
#10 0x00007ffff350330e in nss_load_library (ni=ni@entry=0x6d2d50) at nsswitch.c:358
#11 0x00007ffff3503b58 in __GI___nss_lookup_function (ni=0x6d2d50, fct_name=<optimized out>, fct_name@entry=0x7ffff355f5b3 "gethostbyname_r") at nsswitch.c:466
#12 0x00007ffff3503c4c in __GI___nss_lookup (ni=ni@entry=0x7fffffffc4f0, fct_name=fct_name@entry=0x7ffff355f5b3 "gethostbyname_r", fct2_name=fct2_name@entry=0x0, fctp=fctp@entry=0x7fffffffc4f8) at nsswitch.c:189
#13 0x00007ffff3504cd0 in __GI___nss_hosts_lookup2 (ni=ni@entry=0x7fffffffc4f0, fct_name=fct_name@entry=0x7ffff355f5b3 "gethostbyname_r", fct2_name=fct2_name@entry=0x0, fctp=fctp@entry=0x7fffffffc4f8)
    at XXX-lookup.c:75
#14 0x00007ffff34f5d5c in __gethostbyname_r (name=0x7ffff39fd660 "verstak", resbuf=0x7fffffffc560, buffer=<optimized out>, buflen=2048, result=0x7fffffffc558, h_errnop=0x7fffffffc554) at ../nss/getXXbyYY_r.c:254
#15 0x00007ffff37d817c in ?? () from /opt/libreoffice6.2/program/libuno_sal.so.3
#16 0x00007ffff37d8c7c in osl_getLocalHostname () from /opt/libreoffice6.2/program/libuno_sal.so.3
#17 0x00007fffdfc4457a in vcl_sal::WMAdaptor::setClientMachine(X11SalFrame const*) const () from /opt/libreoffice6.2/program/libvclplug_genlo.so
#18 0x00007fffdfc76e96 in X11SalFrame::Init(SalFrameStyleFlags, SalX11Screen, SystemParentData const*, bool) () from /opt/libreoffice6.2/program/libvclplug_genlo.so
#19 0x00007fffdfc78d91 in X11SalFrame::X11SalFrame(SalFrame*, SalFrameStyleFlags, SystemParentData const*) () from /opt/libreoffice6.2/program/libvclplug_genlo.so
#20 0x00007fffe2b3b28b in ?? () from /opt/libreoffice6.2/program/libvclplug_kde4lo.so
#21 0x00007fffe2b3fe85 in ?? () from /opt/libreoffice6.2/program/libvclplug_kde4lo.so
#22 0x00007ffff64e67c3 in ?? () from /opt/libreoffice6.2/program/libmergedlo.so
#23 0x00007ffff64183ba in ?? () from /opt/libreoffice6.2/program/libmergedlo.so
#24 0x00007ffff641869c in ?? () from /opt/libreoffice6.2/program/libmergedlo.so
#25 0x00007ffff64edad8 in ?? () from /opt/libreoffice6.2/program/libmergedlo.so
#26 0x00007ffff64663bb in IntroWindow::IntroWindow() () from /opt/libreoffice6.2/program/libmergedlo.so
#27 0x00007ffff57a8196 in ?? () from /opt/libreoffice6.2/program/libmergedlo.so
#28 0x00007fffedfaddfb in ?? () from /opt/libreoffice6.2/program/libuno_cppuhelpergcc3.so.3
#29 0x00007fffedface2b in ?? () from /opt/libreoffice6.2/program/libuno_cppuhelpergcc3.so.3
#30 0x00007fffedfad103 in ?? () from /opt/libreoffice6.2/program/libuno_cppuhelpergcc3.so.3
#31 0x00007fffedfadaf9 in ?? () from /opt/libreoffice6.2/program/libuno_cppuhelpergcc3.so.3
#32 0x00007fffedfe80a2 in ?? () from /opt/libreoffice6.2/program/libuno_cppuhelpergcc3.so.3
#33 0x00007fffedfe8368 in ?? () from /opt/libreoffice6.2/program/libuno_cppuhelpergcc3.so.3
#34 0x00007ffff571d98f in ?? () from /opt/libreoffice6.2/program/libmergedlo.so
#35 0x00007ffff5726924 in ?? () from /opt/libreoffice6.2/program/libmergedlo.so
#36 0x00007ffff676d7a2 in ImplSVMain() () from /opt/libreoffice6.2/program/libmergedlo.so
#37 0x00007ffff5747ec5 in soffice_main () from /opt/libreoffice6.2/program/libmergedlo.so
#38 0x000000000040070b in ?? ()
#39 0x00007ffff341b2e1 in __libc_start_main (main=0x400700, argc=1, argv=0x7fffffffde18, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffde08)
    at ../csu/libc-start.c:291
#40 0x000000000040073f in ?? ()

At the same time if I start libreoffice6.2 with environment variable OOO_FORCE_DESKTOP=gnome it starts as expected and shows main screen with recent documents etc.
Comment 2 Max A. Dednev 2019-07-07 19:33:00 UTC
Latest working version is 6.2.3.2, but 6.2.4.1 doesn't start and says "Application Error".
Comment 3 Max A. Dednev 2019-07-07 19:53:42 UTC
Created attachment 152629 [details]
ld log file for libreoffice 6.2.5

Run results from LD_DEBUG=all libreoffice6.2 > log.txt 2>&1 

Warning: about 280 MB decompressed file size.
Comment 4 Max A. Dednev 2019-07-07 20:12:03 UTC
Additional information:
SAL_USE_VCLPLUGIN=gtk3 libreoffice6.2 - works
SAL_USE_VCLPLUGIN=gtk libreoffice6.2 - works
SAL_USE_VCLPLUGIN=kde4 libreoffice6.2 - works with some UI issues (distorted main menu etc.)
SAL_USE_VCLPLUGIN=gen libreoffice6.2 - works

But,
SAL_USE_VCLPLUGIN=genlo libreoffice6.2 - doesn't work (Application Error).
SAL_USE_VCLPLUGIN=kde4lo libreoffice6.2 - doesn't work (Application Error).
SAL_USE_VCLPLUGIN=kde5lo libreoffice6.2 - doesn't work (Application Error).
SAL_USE_VCLPLUGIN=gtklo libreoffice6.2 - doesn't work (Application Error).
SAL_USE_VCLPLUGIN=qt5lo libreoffice6.2 - doesn't work (Application Error).
Comment 5 Xisco Faulí 2019-07-08 10:29:31 UTC
(In reply to Max A. Dednev from comment #4)
> SAL_USE_VCLPLUGIN=genlo libreoffice6.2 - doesn't work (Application Error).
> SAL_USE_VCLPLUGIN=kde4lo libreoffice6.2 - doesn't work (Application Error).
> SAL_USE_VCLPLUGIN=kde5lo libreoffice6.2 - doesn't work (Application Error).
> SAL_USE_VCLPLUGIN=gtklo libreoffice6.2 - doesn't work (Application Error).
> SAL_USE_VCLPLUGIN=qt5lo libreoffice6.2 - doesn't work (Application Error).

that's weird, we don't use those values, see < https://opengrok.libreoffice.org/xref/core/vcl/source/app/salplug.cxx?r=d00ee2cb#230 >
Comment 6 Rene Engelhard 2019-07-08 10:51:58 UTC
So LO shouldn't crash on "invalid" values...
Comment 7 Rene Engelhard 2019-07-08 10:54:50 UTC Comment hidden (obsolete)
Comment 8 Xisco Faulí 2019-07-08 10:58:12 UTC
For the record, it doesn't crash here

Version: 6.4.0.0.alpha0+
Build ID: 9b7729c6e224dfbe89e309aab8e8fd392fc234ad
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded

if I launch LibreOffice with SAL_USE_VCLPLUGIN=genlo instdir/program/scalc
Comment 9 Max A. Dednev 2019-07-08 11:48:44 UTC
(In reply to Xisco Faulí from comment #5)
> that's weird, we don't use those values, see <
> https://opengrok.libreoffice.org/xref/core/vcl/source/app/salplug.
> cxx?r=d00ee2cb#230 >

Yes, you're right. Not all this values are valid, this was brute force.
According to ls -1 /opt/libreoffice6.2/program/libvclplug_*
/opt/libreoffice6.2/program/libvclplug_genlo.so
/opt/libreoffice6.2/program/libvclplug_gtk3_kde5lo.so
/opt/libreoffice6.2/program/libvclplug_gtk3lo.so
/opt/libreoffice6.2/program/libvclplug_gtklo.so
/opt/libreoffice6.2/program/libvclplug_kde4lo.so
/opt/libreoffice6.2/program/libvclplug_kde5lo.so
/opt/libreoffice6.2/program/libvclplug_qt5lo.so

There are more supported plugins, then listed in code above.
Comment 10 Karel Hruska 2019-07-08 14:00:11 UTC
I confirm this bug for LibreOffice 6.2.4.2 and 6.2.5.2 on Debian 9.9 with Plasma 5.8.

As a workaround removal of libreoffice-kde-integration and installation of libreoffice-gnome-integration helps.
Comment 11 Jan-Marek Glogowski 2019-07-08 16:28:02 UTC
#17 0x00007fffdfc4457a in vcl_sal::WMAdaptor::setClientMachine(X11SalFrame const*) const () from /opt/libreoffice6.2/program/libvclplug_genlo.so

This is way after the plugin loader, already running gen.

(In reply to Max A. Dednev from comment #3)
> Created attachment 152629 [details]
> ld log file for libreoffice 6.2.5
> 
> Run results from LD_DEBUG=all libreoffice6.2 > log.txt 2>&1 
> 
> Warning: about 280 MB decompressed file size.

This has a very interesting failure:

      8261:     /usr/lib/x86_64-linux-gnu/libQt5Core.so.5: error: version lookup error: version `Qt_5.9' not found (required by /opt/libreoffice6.2/program/libvclplug_gtk3_kde5lo.so) (fatal)
      8261:     file=/opt/libreoffice6.2/program/libvclplug_gtk3_kde5lo.so [0];  destroying link map

It looks like LO TDF somehow now depends on some versioned Qt_5.9 symbol, if I understand this correctly.

Just that I get this right. LO v6.2.3.2 is still working for you, but 6.2.4.1 doesn't start and crashes? That would very much rule out conflict with some Debian updates.

And you didn't list either the qt5 or the kde5 based plugins without the wrong *lo postfix. What happens with them? I suspect they don't work.

And what desktop are you running?
Comment 12 Max A. Dednev 2019-07-08 19:38:49 UTC
(In reply to Jan-Marek Glogowski from comment #11)
> #17 0x00007fffdfc4457a in vcl_sal::WMAdaptor::setClientMachine(X11SalFrame
> const*) const () from /opt/libreoffice6.2/program/libvclplug_genlo.so
> 
> This is way after the plugin loader, already running gen.
> 
> (In reply to Max A. Dednev from comment #3)
> > Created attachment 152629 [details]
> > ld log file for libreoffice 6.2.5
> > 
> > Run results from LD_DEBUG=all libreoffice6.2 > log.txt 2>&1 
> > 
> > Warning: about 280 MB decompressed file size.
> 
> This has a very interesting failure:
> 
>       8261:     /usr/lib/x86_64-linux-gnu/libQt5Core.so.5: error: version
> lookup error: version `Qt_5.9' not found (required by
> /opt/libreoffice6.2/program/libvclplug_gtk3_kde5lo.so) (fatal)
>       8261:     file=/opt/libreoffice6.2/program/libvclplug_gtk3_kde5lo.so
> [0];  destroying link map
> 
> It looks like LO TDF somehow now depends on some versioned Qt_5.9 symbol, if
> I understand this correctly.

Yes, you're right and I suppose that this is the root of the current issue:
[makc@verstak ~]$ ldd /opt/libreoffice6.2/program/libvclplug_kde5lo.so 
/opt/libreoffice6.2/program/libvclplug_kde5lo.so: /usr/lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.9' not found (required by /opt/libreoffice6.2/program/libvclplug_kde5lo.so)
/opt/libreoffice6.2/program/libvclplug_kde5lo.so: /usr/lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.9' not found (required by /opt/libreoffice6.2/program/libvclplug_qt5lo.so)

[makc@verstak ~]$ ldd /opt/libreoffice6.2/program/libvclplug_qt5lo.so  
/opt/libreoffice6.2/program/libvclplug_qt5lo.so: /usr/lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.9' not found (required by /opt/libreoffice6.2/program/libvclplug_qt5lo.so)

[makc@verstak ~]$ ldd /opt/libreoffice6.2/program/libvclplug_gtk3_kde5lo.so
/opt/libreoffice6.2/program/libvclplug_gtk3_kde5lo.so: /usr/lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.9' not found (required by /opt/libreoffice6.2/program/libvclplug_gtk3_kde5lo.so)

All this plugins depends on newer version of Qt (5.9), but Qt version in Debian 9.9 is much older (5.7.1):
[makc@verstak ~]$ dpkg -l | grep libqt5core
ii  libqt5core5a:amd64                                5.7.1+dfsg-3+deb9u1                         amd64        Qt 5 core module

> Just that I get this right. LO v6.2.3.2 is still working for you, but
> 6.2.4.1 doesn't start and crashes? That would very much rule out conflict
> with some Debian updates.

Yes, but this isn't conflict, this is missing dependency on Qt 5.9.

> And you didn't list either the qt5 or the kde5 based plugins without the
> wrong *lo postfix. What happens with them? I suspect they don't work.

Yes, you've guessed right: gtk3_kde5, kde5 and qt5 aren't work.

> And what desktop are you running?

Plasma 5.8.6-1 (KDE5).

So sudo dpkg --purge libobasis6.2-kde-integration solves this problem under Debian 9.9.
Comment 13 Jan-Marek Glogowski 2019-07-09 00:18:28 UTC
So I checked the 6.2.3 build:

$ objdump -T libvclplug_qt5lo.so | grep qt_version_tag
0000000000000000      DO *UND*  0000000000000000  Qt_5.9      qt_version_tag

Now I would be interested in the About dialog info of your LO 6.2.3. I guess that didn't run qt5 or kde5 either, but kde4. I was wrong with gen, as your backtrace actually shows:

#21 0x00007fffe2b3fe85 in ?? () from /opt/libreoffice6.2/program/libvclplug_kde4lo.so

And I found https://stackoverflow.com/questions/39871879/why-do-i-get-this-error-undefined-reference-to-qt-version-tag

So we should probably run the builds with -DQT_NO_VERSION_TAGGING... we should still be function compatible with Qt 5.6.

All this still doesn't explain why LO started crashing with 6.2.4.

One major change we did for 6.2.4 was to enable the gtk3_kde5 backend. But this is also linked against Qt5, so it would fail to load because of the missing qt_version_tag symbol and according to your logs it does.

Which leaves no real reason for the crash, except for some speculation, that loading and failing libqt5 together with libgtk3 triggers some ld bug (I don't think so) or some .init code in any of the KF5 or Qt5 libraries doesn't clean up correctly, so the later loaded libvclplug_kde4 crashes in NSS code.

What happens if you just remove the /opt/libreoffice6.2/program/libvclplug_gtk3_kde5lo.so library?

In theory this should work with kde4, which still would result in

(In reply to Max A. Dednev from comment #4)
> Additional information:
> SAL_USE_VCLPLUGIN=kde4 libreoffice6.2 - works with some UI issues (distorted
> main menu etc.)

That is a duplicate of bug I can't find anymore. But the regression was quite probably introduced by the fix for bug 125415. I fixed that for kde5 in bug 125673, but nobody tested / fixed kde4.

So this basically leaves you with this: uninstall libobasis6.2-kde-integration (as you already did) and this should use the gtk3 plugin, which is IMHO the best option regarding the circumstances.

FWIW I just tested -DQT_NO_VERSION_TAGGING and it prevents the qt_version_tag symbol, so this will be used in 6.2.6 build and 6.3.
Comment 14 Jan-Marek Glogowski 2019-07-09 00:41:26 UTC
FYI: https://gerrit.libreoffice.org/#/c/75280/
Comment 15 Max A. Dednev 2019-07-09 17:16:29 UTC
(In reply to Jan-Marek Glogowski from comment #13)
> 
> All this still doesn't explain why LO started crashing with 6.2.4.

This is really interesting.

> What happens if you just remove the
> /opt/libreoffice6.2/program/libvclplug_gtk3_kde5lo.so library?

It runs without "Application Error" using kde4 VCL plugin. Here is quote from About LibreOffice:
Version: 6.2.5.2
Build ID: 1ec314fa52f458adc18c4f025c545a4e8b22c159
CPU threads: 4; OS: Linux 4.9; UI render: default; VCL: kde4; 
Locale: en-US (C); UI-Language: en-US
Calc: threaded


> In theory this should work with kde4, which still would result in

Yes, it is.

> FWIW I just tested -DQT_NO_VERSION_TAGGING and it prevents the
> qt_version_tag symbol, so this will be used in 6.2.6 build and 6.3.

Sounds good. :-)
Comment 16 Jan-Marek Glogowski 2019-07-12 09:28:23 UTC
Didn't realize I forget to add myself to CC. Sorry for this late reply and thanks for helping debugging the problem.

(In reply to Jan-Marek Glogowski from comment #13)
> (In reply to Max A. Dednev from comment #4)
> > Additional information:
> > SAL_USE_VCLPLUGIN=kde4 libreoffice6.2 - works with some UI issues (distorted
> > main menu etc.)
> 
> That is a duplicate of bug I can't find anymore. But the regression was
> quite probably introduced by the fix for bug 125415. I fixed that for kde5
> in bug 125673, but nobody tested / fixed kde4.

https://gerrit.libreoffice.org/#/c/75281/ is now merged for 6.2.6 (merged 2019-07-09 22:21), which might fix the menu problem. It should be the equivalent of tdf#125673 for kde4, but I couldn't test, so it's a blind fix (actually I forgot a header, which was fixed by https://gerrit.libreoffice.org/#/c/75381/). 

See https://dev-builds.libreoffice.org/daily/libreoffice-6-2/Linux-rpm_deb-x86_64@86-TDF/ (More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds)

Can you try, if the current daily build is fixed regarding the menu? 

(In reply to Max A. Dednev from comment #15)
> (In reply to Jan-Marek Glogowski from comment #13)
> > 
> > All this still doesn't explain why LO started crashing with 6.2.4.
> 
> This is really interesting.
> 
> > What happens if you just remove the
> > /opt/libreoffice6.2/program/libvclplug_gtk3_kde5lo.so library?
> 
> It runs without "Application Error" using kde4 VCL plugin. Here is quote
> from About LibreOffice:
> Version: 6.2.5.2
> Build ID: 1ec314fa52f458adc18c4f025c545a4e8b22c159
> CPU threads: 4; OS: Linux 4.9; UI render: default; VCL: kde4; 
> Locale: en-US (C); UI-Language: en-US
> Calc: threaded
> 
> > In theory this should work with kde4, which still would result in
> 
> Yes, it is.

I'll ask the other devs, if they have some additional ideas. We might disable gtk3_kde5 again, with these crashes for other plugins...
Comment 17 Jan-Marek Glogowski 2019-07-12 11:35:47 UTC
(In reply to Jan-Marek Glogowski from comment #16)
> I'll ask the other devs, if they have some additional ideas. We might
> disable gtk3_kde5 again, with these crashes for other plugins...

So we had a large discussion on IRC. Nobody came up with a different explanation then "might be a ld bug", from reading your ld debug log.
We'll try to let someone with more experience in this area have a look.
Comment 18 Max A. Dednev 2019-07-13 12:14:01 UTC
(In reply to Jan-Marek Glogowski from comment #16)
 
> 
> https://gerrit.libreoffice.org/#/c/75281/ is now merged for 6.2.6 (merged
> 2019-07-09 22:21), which might fix the menu problem. It should be the
> equivalent of tdf#125673 for kde4, but I couldn't test, so it's a blind fix
> (actually I forgot a header, which was fixed by
> https://gerrit.libreoffice.org/#/c/75381/). 

I've tested following packages:
libreoffice-6-2~2019-07-11_09.35.49_LibreOfficeDev_6.2.6.0.0_Linux_x86-64_deb_helppack_ru.tar.gz
libreoffice-6-2~2019-07-11_09.35.49_LibreOfficeDev_6.2.6.0.0_Linux_x86-64_deb_langpack_ru.tar.gz
libreoffice-6-2~2019-07-11_09.35.49_LibreOfficeDev_6.2.6.0.0_Linux_x86-64_deb.tar.gz

with:
  SAL_USE_VCLPLUGIN=kde4 libreofficedev6.2 - works perfectly for me, no visual issues.
  SAL_USE_VCLPLUGIN=kde5 libreofficedev6.2 - starts without error messages, 'kde5' is shown in About LibreOfficeDev window.
  SAL_USE_VCLPLUGIN=qt5  libreofficedev6.2 - hangs at splash screen, soffice.bin runs at 100% CPU usage but nothing happens. 

According to sysprof it spends most of the time somewhere in libfontconfig. A've attached gdb to hung soffice.bin process and got following backtrace:
#0  0x00007f8dbc3c32ff in ?? () from /usr/lib/x86_64-linux-gnu/libfontconfig.so.1
#1  0x00007f8dbc3c38fa in ?? () from /usr/lib/x86_64-linux-gnu/libfontconfig.so.1
#2  0x00007f8dbc3c2e14 in FcFreeTypeQueryFace () from /usr/lib/x86_64-linux-gnu/libfontconfig.so.1
#3  0x00007f8dbc3c2ec9 in FcFreeTypeQuery () from /usr/lib/x86_64-linux-gnu/libfontconfig.so.1
#4  0x00007f8da9b2aa9d in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#5  0x00007f8daf50ae16 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#6  0x00007f8daf50d637 in QFontDatabase::addApplicationFont(QString const&) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#7  0x00007f8dafdac031 in ?? () from /opt/libreofficedev6.2/program/libvclplug_qt5lo.so
#8  0x00007f8dc38ade09 in ?? () from /opt/libreofficedev6.2/program/libmergedlo.so
#9  0x00007f8dc38ae32c in ?? () from /opt/libreofficedev6.2/program/libmergedlo.so
#10 0x00007f8dc38aea8e in ?? () from /opt/libreofficedev6.2/program/libmergedlo.so
#11 0x00007f8dc38b2119 in OutputDevice::GetTextHeight() const () from /opt/libreofficedev6.2/program/libmergedlo.so
#12 0x00007f8dc37f2cb7 in ?? () from /opt/libreofficedev6.2/program/libmergedlo.so
#13 0x00007f8dc37fee58 in ?? () from /opt/libreofficedev6.2/program/libmergedlo.so
#14 0x00007f8dc37308ba in ?? () from /opt/libreofficedev6.2/program/libmergedlo.so
#15 0x00007f8dc3730b9c in ?? () from /opt/libreofficedev6.2/program/libmergedlo.so
#16 0x00007f8dc38060b8 in ?? () from /opt/libreofficedev6.2/program/libmergedlo.so
#17 0x00007f8dc38064b9 in WorkWindow::WorkWindow(vcl::Window*, long) () from /opt/libreofficedev6.2/program/libmergedlo.so
#18 0x00007f8dc33dc25b in ?? () from /opt/libreofficedev6.2/program/libmergedlo.so
#19 0x00007f8dc33dd29f in ?? () from /opt/libreofficedev6.2/program/libmergedlo.so
#20 0x00007f8dc23b0dc0 in ?? () from /opt/libreofficedev6.2/program/libmergedlo.so
#21 0x00007f8dc22e8659 in ?? () from /opt/libreofficedev6.2/program/libmergedlo.so
#22 0x00007f8dc2381fbb in ?? () from /opt/libreofficedev6.2/program/libmergedlo.so
#23 0x00007f8dc2a3664b in ?? () from /opt/libreofficedev6.2/program/libmergedlo.so
#24 0x00007f8dc2a400cb in ?? () from /opt/libreofficedev6.2/program/libmergedlo.so
#25 0x00007f8dc3a85ec2 in ImplSVMain() () from /opt/libreofficedev6.2/program/libmergedlo.so
#26 0x00007f8dc2a60385 in soffice_main () from /opt/libreofficedev6.2/program/libmergedlo.so
#27 0x000000000040070b in ?? ()
#28 0x00007f8dc07322e1 in __libc_start_main (main=0x400700, argc=2, argv=0x7fffec014728, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffec014718)
    at ../csu/libc-start.c:291
#29 0x000000000040073f in ?? ()

I've tried to start libreofficedev6.2 with qt5 VCL plugin in newly created clean user profile, but result is exactly the same - it hangs.

> See
> https://dev-builds.libreoffice.org/daily/libreoffice-6-2/Linux-rpm_deb-
> x86_64@86-TDF/ (More information about daily builds can be found at:
> https://wiki.documentfoundation.org/Testing_Daily_Builds)
> 
> Can you try, if the current daily build is fixed regarding the menu? 

I've tried. It seems, that daily build fixes all issues with menu and other visuals for kde4 VCL.
Comment 19 Jan-Marek Glogowski 2019-07-13 12:51:52 UTC
(In reply to Max A. Dednev from comment #18)
> (In reply to Jan-Marek Glogowski from comment #16)
>  
> > https://gerrit.libreoffice.org/#/c/75281/ is now merged for 6.2.6 (merged
> > 2019-07-09 22:21), which might fix the menu problem. It should be the
> > equivalent of tdf#125673 for kde4, but I couldn't test, so it's a blind fix
> > (actually I forgot a header, which was fixed by
> > https://gerrit.libreoffice.org/#/c/75381/). 
> 
> I've tested following packages: libreoffice-6-2~2019-07-11_09.35.49_*
...
> with:
>   SAL_USE_VCLPLUGIN=kde4 libreofficedev6.2 - works perfectly for me, no
> visual issues.
>   SAL_USE_VCLPLUGIN=kde5 libreofficedev6.2 - starts without error messages,
> 'kde5' is shown in About LibreOfficeDev window.
>   SAL_USE_VCLPLUGIN=qt5  libreofficedev6.2 - hangs at splash screen,
> soffice.bin runs at 100% CPU usage but nothing happens.

Great, so your Qt5 is >= 5.6 and the "QT_NO_VERSION_TAGGING" fix works as expected.

Just make sure to always check "About LO", as LO will use a fallback, if a plugin doesn't work. SAL_USE_VCLPLUGIN is just a user preference but doesn't enforce anything.

And you didn't test the most interesting use case: not using SAL_USE_VCLPLUGIN / normal startup :-)
Automatically it should select "kde5" for you and "just work (TM)". Does it work for you?

> According to sysprof qt5 spends most of the time somewhere in libfontconfig.

The font registration for qt5 is slow, because Qt always parses the whole font. There is a reason why it's never selected automatically. You could switch it from QPainter to Cairo by using SAL_VCL_QT5_USE_CAIRO=1, which is the same the kde5 plugin does. Still even for a lot of fonts it shouldn't use more then a minute.

And there is some font variant naming problem in Qt. Somehow Qt misses some fonts on startup from fontconfig and LO tries to register them. Anyway qt5 + QPainter is considered experimental playground. This needs additional work, but we had enough bugs with kde5, so work on it is postponed (there are also pending patches to run qt5 on Windows and MacOS).

> > Can you try, if the current daily build is fixed regarding the menu?
>
> I've tried. It seems, that daily build fixes all issues with menu and other
> visuals for kde4 VCL.

Great :-)

So except for the automatic selection test it looks like we're good for 6.2.6 with regard to these crashes.

Can you test without SAL_USE_VCLPLUGIN too?
Comment 20 Max A. Dednev 2019-07-13 13:07:57 UTC
(In reply to Jan-Marek Glogowski from comment #19)

> Just make sure to always check "About LO", as LO will use a fallback, if a
> plugin doesn't work. SAL_USE_VCLPLUGIN is just a user preference but doesn't
> enforce anything.

Ok, I see and now I always check this information.

> And you didn't test the most interesting use case: not using
> SAL_USE_VCLPLUGIN / normal startup :-)
> Automatically it should select "kde5" for you and "just work (TM)". Does it
> work for you?

I'm sorry, I've checked this before others checks and this works fine. I see "kde5" in "About LO" as you expected.

> 
> > According to sysprof qt5 spends most of the time somewhere in libfontconfig.
> 
> The font registration for qt5 is slow, because Qt always parses the whole
> font. There is a reason why it's never selected automatically. You could
> switch it from QPainter to Cairo by using SAL_VCL_QT5_USE_CAIRO=1, which is
> the same the kde5 plugin does. Still even for a lot of fonts it shouldn't
> use more then a minute.

I've tried to run win cairo, but result is roughly the same - no main window appeared, but LO doesn't use 100% CPU, but hanged.
I've got following backtrace with attached gdb:
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007fe3ba14d50c in std::condition_variable::wait(std::unique_lock<std::mutex>&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#2  0x00007fe3b0969d8b in Qt5Instance::RunInMainThread(std::function<void ()>) () from /opt/libreofficedev6.2/program/libvclplug_qt5lo.so
#3  0x00007fe3b0969ef5 in Qt5Instance::CreateMenu(bool, Menu*) () from /opt/libreofficedev6.2/program/libvclplug_qt5lo.so
#4  0x00007fe3c434b4b1 in PopupMenu::PopupMenu() () from /opt/libreofficedev6.2/program/libmergedlo.so
#5  0x00007fe3c430726e in VclBuilder::handleMenu(xmlreader::XmlReader&, rtl::OString const&) () from /opt/libreofficedev6.2/program/libmergedlo.so
#6  0x00007fe3c4307b9c in VclBuilder::handleObject(vcl::Window*, xmlreader::XmlReader&) () from /opt/libreofficedev6.2/program/libmergedlo.so
#7  0x00007fe3c43063ca in VclBuilder::handleChild(vcl::Window*, xmlreader::XmlReader&) () from /opt/libreofficedev6.2/program/libmergedlo.so
#8  0x00007fe3c430a7cf in VclBuilder::VclBuilder(vcl::Window*, rtl::OUString const&, rtl::OUString const&, rtl::OString const&, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&, bool) ()
   from /opt/libreofficedev6.2/program/libmergedlo.so
#9  0x00007fe3c33bbdad in ?? () from /opt/libreofficedev6.2/program/libmergedlo.so
#10 0x00007fe3c33b4ab3 in ?? () from /opt/libreofficedev6.2/program/libmergedlo.so
#11 0x00007fe3bbeba068 in ?? () from /opt/libreofficedev6.2/program/libuno_cppuhelpergcc3.so.3
#12 0x00007fe3bbeba368 in ?? () from /opt/libreofficedev6.2/program/libuno_cppuhelpergcc3.so.3
#13 0x00007fe3c35fc1b6 in ?? () from /opt/libreofficedev6.2/program/libmergedlo.so
#14 0x00007fe3c35f16f0 in ?? () from /opt/libreofficedev6.2/program/libmergedlo.so
#15 0x00007fe3c35fb0cb in ?? () from /opt/libreofficedev6.2/program/libmergedlo.so
#16 0x00007fe3c4640ec2 in ImplSVMain() () from /opt/libreofficedev6.2/program/libmergedlo.so
#17 0x00007fe3c361b385 in soffice_main () from /opt/libreofficedev6.2/program/libmergedlo.so
#18 0x000000000040070b in ?? ()
#19 0x00007fe3c12ed2e1 in __libc_start_main (main=0x400700, argc=2, argv=0x7ffe3513d0b8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe3513d0a8)
    at ../csu/libc-start.c:291
#20 0x000000000040073f in ?? ()

It stucked.

> And there is some font variant naming problem in Qt. Somehow Qt misses some
> fonts on startup from fontconfig and LO tries to register them. Anyway qt5 +
> QPainter is considered experimental playground. This needs additional work,
> but we had enough bugs with kde5, so work on it is postponed (there are also
> pending patches to run qt5 on Windows and MacOS).

But as I can understand, kde5 uses Qt5 framework and it works fine. How could it happen?

> 
> So except for the automatic selection test it looks like we're good for
> 6.2.6 with regard to these crashes.
> 
> Can you test without SAL_USE_VCLPLUGIN too?

It just works. :-)
Comment 21 Jan-Marek Glogowski 2019-07-13 13:46:19 UTC
(In reply to Max A. Dednev from comment #20)
> (In reply to Jan-Marek Glogowski from comment #19) 
> > And you didn't test the most interesting use case: not using
> > SAL_USE_VCLPLUGIN / normal startup :-)
> > Automatically it should select "kde5" for you and "just work (TM)". Does it
> > work for you?
> 
> I'm sorry, I've checked this before others checks and this works fine. I see
> "kde5" in "About LO" as you expected.

Good.

> I've tried to run qt5 with cairo, but result is roughly the same - no main window
> appeared, but LO doesn't use 100% CPU, but hanged.
>
> I've got following backtrace with attached gdb:
> #0  pthread_cond_wait@@GLIBC_2.3.2 () at
> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
> #1  0x00007fe3ba14d50c in
> std::condition_variable::wait(std::unique_lock<std::mutex>&) () from
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> #2  0x00007fe3b0969d8b in Qt5Instance::RunInMainThread(std::function<void
> ()>) () from /opt/libreofficedev6.2/program/libvclplug_qt5lo.so
> #3  0x00007fe3b0969ef5 in Qt5Instance::CreateMenu(bool, Menu*) () from
> /opt/libreofficedev6.2/program/libvclplug_qt5lo.so
> #4  0x00007fe3c434b4b1 in PopupMenu::PopupMenu() () from
> /opt/libreofficedev6.2/program/libmergedlo.so
> #5  0x00007fe3c430726e in VclBuilder::handleMenu(xmlreader::XmlReader&,
> rtl::OString const&) () from /opt/libreofficedev6.2/program/libmergedlo.so
> #6  0x00007fe3c4307b9c in VclBuilder::handleObject(vcl::Window*,
> xmlreader::XmlReader&) () from /opt/libreofficedev6.2/program/libmergedlo.so
> #7  0x00007fe3c43063ca in VclBuilder::handleChild(vcl::Window*,
> xmlreader::XmlReader&) () from /opt/libreofficedev6.2/program/libmergedlo.so
> #8  0x00007fe3c430a7cf in VclBuilder::VclBuilder(vcl::Window*, rtl::OUString
> const&, rtl::OUString const&, rtl::OString const&,
> com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&, bool)
> ()
>    from /opt/libreofficedev6.2/program/libmergedlo.so
> #9  0x00007fe3c33bbdad in ?? () from
> /opt/libreofficedev6.2/program/libmergedlo.so
> #10 0x00007fe3c33b4ab3 in ?? () from
> /opt/libreofficedev6.2/program/libmergedlo.so
> #11 0x00007fe3bbeba068 in ?? () from
> /opt/libreofficedev6.2/program/libuno_cppuhelpergcc3.so.3
> #12 0x00007fe3bbeba368 in ?? () from
> /opt/libreofficedev6.2/program/libuno_cppuhelpergcc3.so.3
> #13 0x00007fe3c35fc1b6 in ?? () from
> /opt/libreofficedev6.2/program/libmergedlo.so
> #14 0x00007fe3c35f16f0 in ?? () from
> /opt/libreofficedev6.2/program/libmergedlo.so
> #15 0x00007fe3c35fb0cb in ?? () from
> /opt/libreofficedev6.2/program/libmergedlo.so
> #16 0x00007fe3c4640ec2 in ImplSVMain() () from
> /opt/libreofficedev6.2/program/libmergedlo.so
> #17 0x00007fe3c361b385 in soffice_main () from
> /opt/libreofficedev6.2/program/libmergedlo.so
> #18 0x000000000040070b in ?? ()
> #19 0x00007fe3c12ed2e1 in __libc_start_main (main=0x400700, argc=2,
> argv=0x7ffe3513d0b8, init=<optimized out>, fini=<optimized out>,
> rtld_fini=<optimized out>, stack_end=0x7ffe3513d0a8)
>     at ../csu/libc-start.c:291
> #20 0x000000000040073f in ?? ()
> 
> It stucked

That is a new problem. And kde5 should also be hit by it. I'll have a look, if I can find something obvious, that is different for qt5 and kde5 in this regard, but I currently have no idea.

If you're interested in debugging this, please open a new bug report. Both qt5 and qt5+cairo work for me with Qt 5.11. It might be a bug in the older Qt version...

Does a master daily build work for you with qt5 / qt5+cairo?

> > And there is some font variant naming problem in Qt. Somehow Qt misses some
> > fonts on startup from fontconfig and LO tries to register them. Anyway qt5 +
> > QPainter is considered experimental playground. This needs additional work,
> > but we had enough bugs with kde5, so work on it is postponed (there are also
> > pending patches to run qt5 on Windows and MacOS).
> 
> But as I can understand, kde5 uses Qt5 framework and it works fine. How
> could it happen?

Technically kde5 uses qt5 for almost everything. Very little code uses kf5 specific calls in kde5.

qt5 implements two rendering paths, which mainly affect the font handling and text layout: naive QPainter and Cairo. Native qt5 uses Qt's drawing, font and text layout functions. qt5+cairo uses LO's own text layout functions, which just use cairo for drawing. In the end this uses Cairo for most drawing operations and the resulting Cairo surface is just blitted to the QImage on paint. This way we guarantee that the kde5 layout looks the same then all the other unix backends. And as you can see it, native Qt needs much more work. Everything else, which is still a lot, uses common Qt code.

> > So except for the automatic selection test it looks like we're good for
> > 6.2.6 with regard to these crashes.
> > 
> > Can you test without SAL_USE_VCLPLUGIN too?
> 
> It just works. :-)

Good (again, I asked twice to be sure ;-)
Comment 22 Xisco Faulí 2019-07-15 11:29:11 UTC
*** Bug 126351 has been marked as a duplicate of this bug. ***
Comment 23 marco 2019-10-11 16:23:42 UTC
Hi everyone,
I had a similar issue with Ubuntu 16.04 .  Libreoffice 6.3 will not start, and looking at crash dump I found this:

ldd /opt/libreoffice6.3/program/libvclplug_gtk3_kde5lo.so /opt/libreoffice6.3/program/libvclplug_gtk3_kde5lo.so: /usr/lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5' not found (required by /opt/libreoffice6.3/program/libvclplug_gtk3_kde5lo.so)


The only easy solution was to uninstall libobasis6.2-kde-integration. Now libreoffice works.