When typing via IBus libpinyin when "Record tracked changes" is active, Writer crashes more or less immediately. I could reproduce this both on new documents and editing previously created docs. Quickest way to reproduce: * Start on fresh install (or factory reset) of LibreOffice * Create a new Writer document * Switch to libpinyin input mode. In Ubuntu system settings showing as "Chinese (Intelligent Pinyin)" * Enable "Record tracked changes" * Type and commit some text, like "阿". Type text again like "阿". Writer would crash immediately when typing the second text, before committing it in pinyin/ibus input. Reproduced on Ubuntu 24.04 and Ubuntu 26.10 hosts, both with flatpak from flathub (app/org.libreoffice.LibreOffice/x86_64/stable) and deb packages from libreoffice.org. First seen on version 26.2.1.2 (X86_64). I'm regularly using the flatpak version, so the bug must be fairly recent. Versions 25.8.5 from libreoffice.org and Ubuntu packaged version 25.8.4-0ubuntu0.25.10.1 don't have this bug.
Assertion printed on crash: flatpak version: /usr/include/c++/15.2.0/bits/stl_vector.h:1282: constexpr std::vector<_Tp, _Alloc>::const_reference std::vector<_Tp, _Alloc>::operator[](size_type) const [with _Tp = SwRangeRedline*; _Alloc = std::allocator<SwRangeRedline*>; const_reference = SwRangeRedline* const&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.
Version 26.2.0.3 is not affected
reproduce on windows + Microsoft IME, Google Japanese Input Version: 26.2.1.2 (X86_64) Build ID: 620(Build:2) CPU threads: 8; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Vulkan; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: threaded bibisected with win64-26.8 commit a24dd7b1d742ccd59768db8b6b6a522588952108 author Miklos Vajna cool#13574 sw redline render mode: avoid coloring, set lightness *** adding CC: Miklos Vajna Please, take a look?
Thanks for the bisect. I haven't really used IME so far, could you please tell me how to do these steps: > Switch to libpinyin input mode. In Ubuntu system settings showing as "Chinese (Intelligent Pinyin)" and > Type and commit some text, like "阿". Type text again like "阿". ? I understand this is trivial to you, but it'll be the first time for me, since I only speak English and Hungarian. Thanks.
Sure, please try these steps, they should work on at least Ubuntu 22.04 and later. Just realizing how cumbersome this is.. * apt install ibus-libpinyin * Restart you system (or at least desktop environment), otherwise the new ibus functionality won't be available. * Go into system settings > Keyboard > on top "Input Source" select "Add Input Sources...". In the new window click three dots at the bottom of the list, then type "Chinese", then select "Other" in the list, then select "Chinese (Intelligent Pinyin)" and "Add" Now you would have Pinyin input available. Check language/input toggle in the notification area next to network settings etc (towards the right side of notification bar on the top of the screen). In that list you would now see your previous keyboard layouts, plus the new "Chinese (Intelligent Pinyin)". Now if you select Chinese and then open the list once again, then below the language list you will now see extra settings. The first entry will show either "English" or "Chinese". "Chinese" means pinyin input is enabled, "English" means your main keyboard/language input is enabled. Meanwhile the notification bar icon shows either 中 (pinyin) or 英 (English/default input). Once pinyin is active and you type anywhere, you'll get this ibus selection list pop up next to the text input cursor. The quickest test case would be to just type "a" and then "1". That will select and commit whatever Chinese character shows up as first choice for pinyin "a", which will probably be "阿". On my side the Libreoffice crash sometimes happen the first type typing and committing a character via ibus/pinyin, sometimes only when the ibus selection opens for the second time. Note that with the ibus pinyin input, while the ibus selection window is open, the input system is in preedit mode (not sure if that's the term ibus would use internally though). During preedit mode ibus will already post the candidate characters into the application text field. But until actually committing to a candidate, ibus will keep replacing/removing the candidate depending on what you do in the candidate window. I've seen this behavior causing odd behavior in other cases, like on some websites via Firefox. Hope that helps
AI-generated revised proposal It didn't crash. /sw/source/core/text/itrpaint.cxx @@ -149,7 +149,7 @@ SwTextPaintOmitter::SwTextPaintOmitter(SwTextPainter& rPainter, const SwRedlineT } SwRedlineTable::size_type nRedline = rPainter.GetRedln()->GetAct(); - if (nRedline == SwRedlineTable::npos) + if (nRedline == SwRedlineTable::npos || nRedline >= rRedlineTable.size()) { return; }
(In reply to Karsten Tausche from comment #5) > Sure, please try these steps Thanks, managed to reproduce the problem.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2c8e2b71d7c6630c14229f194682a7a1b198d3e1 tdf#171191 sw redline render mode: fix crash on IME input It will be available in 26.8.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.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-26-2": https://git.libreoffice.org/core/commit/88331a6e8f7c25c0a987c9316737ec046478bca1 tdf#171191 sw redline render mode: fix crash on IME input It will be available in 26.2.3. 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.
Just tested on daily 2026-04-09_02.57.58 / 26.2.3.0.0, fix is working. Thanks!