Created attachment 195645 [details] ODT document with 2 lines of text including a big ligature Description: LibreOffice Writer crashes upon loading text that contains a big ligature: ﷽ Steps to Reproduce: 1. Open attached .odt file Actual Results: Crash Expected Results: LibreOffice Writer should not crash Reproducible: Always User Profile Reset: No Additional Info: Version: 24.2.2.2 (X86_64) / LibreOffice Community Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01 CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
The crash also happens with the latest LO 25.2 dev master on Linux: Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f806fc136b3410ec9a1e09320d100c78b33c867b CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 195652 [details] GDB backtrace
I set the bug as Linux specific as the crash does not happen on Windows: Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2 CPU threads: 20; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded And not with the latest LO 25.2 dev master: Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 514d7384470434a0b0b119e369ff615e2a1499c9 CPU threads: 20; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
I tried to reproduce this issue, but I couldn't. The test document opens correctly for me on Linux. Version: 24.2.5.2 (X86_64) / LibreOffice Community Build ID: d6e8b0f3fc6e8af2b00cf4969fd0d2fa45b9a62e CPU threads: 32; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: cfd3b14fd4e1ee889dd356523e5cdaa639786d37 CPU threads: 32; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: cfd3b14fd4e1ee889dd356523e5cdaa639786d37 CPU threads: 32; OS: Linux 6.8; UI render: Skia/Vulkan; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: cfd3b14fd4e1ee889dd356523e5cdaa639786d37 CPU threads: 32; OS: Linux 6.8; UI render: Skia/Raster; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Just for the record, on pc Debian x86-64 with master sources updated today, I don't reproduce this. I don't reproduce this too with LO Debian package 24.2.5.2 (tested with gtk3 rendering each time)
No repro. Hossein: can you try in Safe Mode? Arch Linux 64-bit Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5c64b81b4d5bd347e57ba156bb0c34d09fb6aa5b CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 5 September 2024
(In reply to Buovjaga from comment #6) > No repro. > > Hossein: can you try in Safe Mode? I have tested safe mode, resetting all the configuration files: (*) Reset to factory settings [x] Reset settings and user interface modification [x] Reset entire user profile The crash happens with the latest LO 25.2 dev master from today: Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f70276214149b8497c755f117bed8104cc1f783a CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
[Automated Action] NeedInfo-To-Unconfirmed
Can't repro on: Version: 25.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: eaef1432bd0799bbed8dcbd6286942ed1d54ad90 CPU threads: 8; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
Crash still reproducible with the latest LO 25.2 dev master: Version: 25.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 9a14a0fd8b4227b5d08b3154cddca46f82ec2a03 CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Use gen backend, I do not see immediate crash but: Version: 25.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 9a14a0fd8b4227b5d08b3154cddca46f82ec2a03 CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded 1. It goes to 277% zoom level upon loading the document, but the main document display canvas is not painted. Content of other Windows is visible there. 2. If I reduce the zoom level to ~100%, the document is rendered. 3. The big ligature shakes badly. This is reported elsewhere, but with this ligature, it is very obvious. 4. When increasing the zoom level, painting the document display canvas stops on values > 200%.
(In reply to Hossein from comment #11) > Use gen backend, I do not see immediate crash but: > > 1. It goes to 277% zoom level upon loading the document, but the main > document display canvas is not painted. Content of other Windows is visible > there. > > 2. If I reduce the zoom level to ~100%, the document is rendered. This is a call to cairo_show_glyphs() failing with CAIRO_STATUS_FREETYPE_ERROR. I can't reproduce the failure at zoom level 277%. It only happens for me at zoom level 490%. It also only happens for me if subpixel antialiasing is enabled.
(In reply to Jonathan Clark from comment #12) > I can't reproduce the failure at zoom level 277%. It only happens for me at > zoom level 490%. It also only happens for me if subpixel antialiasing is > enabled. Might be because I use 2x display scaling. Therefore, I see the issue in zoom levels around half of what causes problems on your display. And yes, I have "Antialiasing" set to "Subpixel (for LCD screens)" in GNOME. Setting "Antialiasing" to other values like "Standard (grayscale)" and "None" prevents crash, and text rendering is done those cases, even with the maximum zoom level which is ~600%.
Still reproducible with the latest LO 25.2 stable: Version: 25.2.0.3 (X86_64) / LibreOffice Community Build ID: e1cf4a87eb02d755bce1a01209907ea5ddc8f069 CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: CL threaded And also with the latest LO 25.8 dev master: Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b96c634d3190dc5441548be1752da13c47d293fd CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: CL threaded
Not reproduced in Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b6953ce38b0117efc5e2023fb7641b764c357fad CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded
(In reply to Xisco Faulí from comment #15) > Not reproduced in > > Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: b6953ce38b0117efc5e2023fb7641b764c357fad > CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3 > Locale: es-ES (es_ES.UTF-8); UI: en-US > Calc: threaded This problem depends also on the display scaling. If you use 2x or 3x scaling on the display, you may see the crash easier/sooner. Otherwise, you have to zoom much more.
(In reply to Hossein from comment #16) > (In reply to Xisco Faulí from comment #15) > > Not reproduced in > > > > Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community > > Build ID: b6953ce38b0117efc5e2023fb7641b764c357fad > > CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3 > > Locale: es-ES (es_ES.UTF-8); UI: en-US > > Calc: threaded > This problem depends also on the display scaling. If you use 2x or 3x > scaling on the display, you may see the crash easier/sooner. Otherwise, you > have to zoom much more. Per above discussion, it also depends on whether subpixel antialiasing is enabled. Subpixel antialiasing makes FreeType internally rasterize at a higher horizontal resolution. On my machine, this is necessary to reproduce the repainting issue described in comment 11 (which is due to FreeType failing to rasterize the glyph; see comment 12). I still can't reproduce the crash. There is a real issue here, I'm just not sure how we should file it. FreeType shouldn't fail to rasterize wide glyphs. However, we also probably shouldn't silently fail to repaint the screen if that happens.