Created attachment 180723 [details] sample file Steps to reproduce: 1. Open attached document 2. Select all 3. Copy 4. Paste Reproduced in Version: 7.4.0.0.alpha1+ / LibreOffice Community Build ID: d4123356c61db269651e950a0a2cc93e6d801c90 CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: x11 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded
Regression introduced by: author Aron Budea <aron.budea@collabora.com> 2018-03-25 08:33:16 +0200 committer Aron Budea <aron.budea@collabora.com> 2018-03-26 15:44:07 +0200 commit 7b1d50e97eaa00855152e74f42b789fc643e0bac (patch) tree 66d4e710ba020e3bc18533a464e356ca07619ea7 parent 4f268695787ff6c7052269058f7ae6de34abfd5d (diff) tdf#106746: pDelPam is a bit special Bisected with: bibisect-linux64-6.1 Adding Cc: to Aron Budea
For the record, my change simply reintroduced the behavior before the regressing commit identified in bug 106746 (hash: db17d3c17c40d6b0e92392cf3c6e343d1d17b771), and indeed, the crash is present at the commit preceding that (also eg. in 5.1.0.3). But it's still a regression, and could be bibisected to the following commit using repo bibisect-50max. Same commit as found in bug 143276, bug 143215, bug 143278 and bug 144270. Adding CC: to Michael Stahl. https://cgit.freedesktop.org/libreoffice/core/commit/?id=c4cf85766453982f1aa94a7f2cb22af19ed100be author Michael Stahl <mstahl@redhat.com> 2015-05-05 23:15:20 +0200 committer Michael Stahl <mstahl@redhat.com> 2015-05-06 00:10:17 +0200 sw: fix crash due to redlines on tables on ooo121112-2.docx
Created attachment 180738 [details] Backtrace Attaching backtrace taken with LO 7.5.0.0.alpha0+ (3ad12672e924f7aef394119f9fe5f0b06a900b9e) debug build. Also saw this on the console: /usr/include/c++/9/debug/array:155: In function: constexpr std::__debug::array<_Tp, _Nm>::value_type& std::__debug::array<_Tp, _Nm>::operator[](std::__debug::array<_Tp, _Nm>::size_type) [with _Tp = BigPtrEntry*; long unsigned int _Nm = 1000; std::__debug::array<_Tp, _Nm>::reference = BigPtrEntry*&; std::__debug::array<_Tp, _Nm>::value_type = BigPtrEntry*; std::__debug::array<_Tp, _Nm>::size_type = long unsigned int] Error: attempt to subscript container with out-of-bounds index 32450, but container only holds 1000 elements. Objects involved in the operation: sequence "this" @ 0x0x1b { type = std::__debug::array<BigPtrEntry*, 1000ul>; }
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/de49e1c55dc10ce1b59345af5cc49fde3adf65b7 tdf#149548 sw: don't rely on binary search in SplitRedline() It will be available in 7.5.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.
Michael, thanks for fixing! Does the following mean that there is a problem with the bugdoc and such documents should normally not be created? "The problem is that for this bugdoc overlapping redlines are created by writerfilter"
(In reply to Aron Budea from comment #5) > Michael, thanks for fixing! Does the following mean that there is a problem > with the bugdoc and such documents should normally not be created? > > "The problem is that for this bugdoc overlapping redlines are created by > writerfilter" mainly it means that Writer shouldn't create such redlines, probably by splitting them up differently, but it looks like quite some work to fix that.
Hi Michael, unfortunately the issue is still reproducible in Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: c4f7043c593823b8c5605e779371ff430659eb20 CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded following the steps in the description.
bibisect finds that it worked on my commit but started to crash with this: commit 2fe4de5167eb70e40a7d2f6e9c68247d2b151775 Author: Jenkins Build User <tdf@pollux.tdf> Date: Tue Jul 19 19:14:42 2022 +0200 source 4701d17bfe785f00958ad58a63dc0ece4c5c3281 ...i'm afraid there are some long-standing problems such as overlapping SwRangeRedlines that prevent optimizing this stuff. for me reverting this commit makes it not crash on paste, see: https://gerrit.libreoffice.org/c/core/+/138094 (i found an unrelated crash that happens when you copy all, then close the document, then copy anything else (clearing the first clipboard document), looks like an SfxItemPool UAF)
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/656ff63ed045dfaedff7f34dc4adc0b203850543 tdf#149548 Revert "tdf#119840 loop backwards in ... It will be available in 7.5.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.
(In reply to Michael Stahl (allotropia) from comment #8) > (i found an unrelated crash that happens when you copy all, then close the > document, then copy anything else (clearing the first clipboard document), > looks like an SfxItemPool UAF) Reported in bug 150441
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/fa5838b018a5f1e5b1616bbacbb242eb4fac998a tdf#149548 sw: don't rely on binary search in SplitRedline() It will be available in 7.4.1. 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.
Verified in Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 8475b367298de73aec6abc60a159cc015baf9734 CPU threads: 14; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (hu_HU); UI: en-US Calc: threaded Copy-paste of the whole document content does not crash.
Oh no - Copy all and close LO does crash :(.
(In reply to Gabor Kelemen (allotropia) from comment #13) > Oh no - Copy all and close LO does crash :(. Crash or Assert. Assert is reported in bug 147731 & as duplicate of bug 147731
(In reply to Telesto from comment #14) > (In reply to Gabor Kelemen (allotropia) from comment #13) > > Oh no - Copy all and close LO does crash :(. > > Crash or Assert. Assert is reported in bug 147731 & as duplicate of bug > 147731 Crash. Seems to have started in 6.1 or 6.2, so probably not a duplicate of the above. Will bibisect and file a new one.
*** Bug 150498 has been marked as a duplicate of this bug. ***
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4cc101bfc362d4aea1ecc9136b20b73910fa0041 tdf#149548 sw: add unit test It will be available in 7.6.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.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/05c423c6a9ebdc432053194431c12bf3bdaf8546 tdf#149548 sw: add unit test It will be available in 7.5.0.0.beta2. 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.