https://bugs.documentfoundation.org/show_bug.cgi?id=126272
Jan-Marek Glogowski <glo...@fbihome.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #21 from Jan-Marek Glogowski <glo...@fbihome.de> ---
(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 ;-)
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs