Same bug from other user:
https://superuser.com/questions/1451070/libreoffce-6-2-4-wont-start-after-upgrade-on-debian-9-9

Latest working version is 6.2.3.2, but 6.2.4.1 doesn't start and says "Application Error".

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.

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).

(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 >

So LO shouldn't crash on "invalid" values...

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

(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.

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.

#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?

(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.

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.

FYI: https://gerrit.libreoffice.org/#/c/75280/

(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. :-)

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...

(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.

(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.

(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?

(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. :-)

(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 ;-)

*** Bug 126351 has been marked as a duplicate of this bug. ***

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.