Bug 137804 - Qt5 printing (from Writer) crashes LibreOffice
Summary: Qt5 printing (from Writer) crashes LibreOffice
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
7.1.0.0.alpha0+
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.1.0 target:7.0.4
Keywords:
Depends on:
Blocks: Qt5
  Show dependency treegraph
 
Reported: 2020-10-27 15:38 UTC by Jan-Marek Glogowski
Modified: 2020-10-28 06:02 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan-Marek Glogowski 2020-10-27 15:38:47 UTC
This might be a new or an unveiled bug since fixing bug 125234, but I didn't test this. It was originally found when the reporter of bug 136915 tried to print after my fix for it. I reverted that fix and found it still crashed LO when opening the print dialog.

There is already a fix, so this is just for documentation. While I won't backport all the fixes for bug 125234 and follow up (see bug 125234 comment 31), fixing this crash is easy enough and independent. The following text is from the comment I planned to add to bug 136915 originally.

----

Guess I should have just tested printing to PDF. Interestingly it doesn't happen when running LO in gdb. It did happen in valgrind, but that would just spew a lot of Qt error messages, starting with:

ASSERT failure in QVector<T>::operator[]: "index out of range", file /usr/include/x86_64-linux-gnu/qt5/QtCore/qvector.h, line 431
QPainter::begin: A paint device can only be painted by one painter at a time.
QPainter::setClipRegion: Painter not active
QPainter::setPen: Painter not active
QPainter::setCompositionMode: Painter not active
QPainter::begin: A paint device can only be painted by one painter at a time.
QPainter::setClipRegion: Painter not active
QPainter::setPen: Painter not active
...

but also no valgrind backtrace :-(

So I had to stick a std::abort() into the ::Qt5Painter as a reaction to begin(QPaintDevice *) failures, so the general KDE crash handler could collect a backtrace for me.

But the real question is: why does LO try to layout quite a few empty strings?
Comment 1 Commit Notification 2020-10-27 19:20:28 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/feb5985b463974476985dee83376067941d77da0

tdf#137804 Qt5 don't paint empty strings

It will be available in 7.1.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 2 Commit Notification 2020-10-28 06:02:57 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/dc44470620857fae533246f4cb1038b3e9d2b2bd

tdf#137804 Qt5 don't paint empty strings

It will be available in 7.0.4.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.