Bug 148954 - Writer Crash on loading files with RTL/CTL text and certain glyphs (debug build only)
Summary: Writer Crash on loading files with RTL/CTL text and certain glyphs (debug bui...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.4.0.0 alpha0+
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard: target:7.4.0
Keywords: bisected, haveBacktrace, regression, text:ctl, text:rtl
Depends on:
Blocks: Crash-Assert RTL-Arabic-and-Farsi
  Show dependency treegraph
 
Reported: 2022-05-05 23:19 UTC by Hossein
Modified: 2022-07-25 18:56 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Text layout bug that leads to crash (10.44 KB, application/vnd.oasis.opendocument.text)
2022-05-05 23:19 UTC, Hossein
Details
Backtrace (66.76 KB, text/plain)
2022-05-05 23:26 UTC, Hossein
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hossein 2022-05-05 23:19:52 UTC
Created attachment 179951 [details]
Text layout bug that leads to crash

Description:
Upon loading files with RTL/CTL text and certain glyphs, the debug build of the latest LibreOffice 7.4 master build crashes.

Steps to Reproduce:
1. Run LibreOffice 7.4 master build
2. Open laypout-bug.odt

Actual Results:  
The debug build of LibreOffice crashes every time

Expected Results:
LibreOffice should be able to open the odt file without crashing


Reproducible: Always


User Profile Reset: No



Additional Info:

Amiri font is needed:
https://github.com/aliftype/amiri/releases

+ With Arial font, Writer does not crash.
+ With automatic color of the text, Writer does not crash

Not reproducible in 7.3:

Version: 7.3.0.3 / LibreOffice Community
Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3
CPU threads: 8; OS: Linux 5.13; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Reproducible in the latest 7.4 master:

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: cf7e3ac040d1249f6df0d6796e11d834285680f0
CPU threads: 8; OS: Linux 5.13; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 1 Hossein 2022-05-05 23:26:44 UTC
Created attachment 179952 [details]
Backtrace

Backtrace for the crash while loading laypout-bug.odt

The crash happens in:

soffice.bin: vcl/source/gdi/impglyphitem.cxx:277: void checkGlyphsEqual(const SalLayoutGlyphs&, const SalLayoutGlyphs&): Assertion `l1->isEqual(l2)' failed.
Unspecified Application Error


Fatal exception: Signal 6
Comment 2 Caolán McNamara 2022-05-06 09:01:19 UTC
yeah, I see this also with https://bugs.documentfoundation.org/attachment.cgi?id=179385 and cursoring through the first and second lines
Comment 3 Hossein 2022-05-06 22:34:06 UTC
Bisected to:
 0a6d946694e4fcb39228c5e1fec58fcfd8a45989 is the first bad commit
commit 0a6d946694e4fcb39228c5e1fec58fcfd8a45989
Author: Luboš Luňák <l.lunak@collabora.com>
Date:   Wed Apr 27 09:52:04 2022 +0200

optimize repeated calls for the same string in SalLayoutGlyphsCache
Comment 4 Commit Notification 2022-05-11 17:01:17 UTC
Luboš Luňák committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/5caa7f44b861876afa5b3b8f71e3848abd8875e6

fix HB_GLYPH_FLAG_UNSAFE_TO_BREAK for RTL in cloneCharRange() (tdf#148954)

It will be available in 7.4.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 5 Hossein 2022-05-11 18:46:13 UTC
I verify that the crash no longer happens with the latest patch from Luboš.

I have also tested with another big Persian document. LibreOffice was crashing before, and now it loads the file without crash.