Created attachment 163288 [details] Example file This bug was filed from the crash reporting server and is br-178e1041-139f-4cb8-8b5e-e55e20bb5759. ========================================= 1. Open the attached file 2. Enter table cell A1 (so first cell) 3. Press Delete row until orange (sometimes 4/5 extra) 4. Press CTRL+Z -> Crash
Until : K Cl. I bodu 194 – § 63:
No repro with Version: 6.2.4.0.0+ Build ID: 915ec0b5f5ce9a2da6a51f5278ea4faaffa19839 CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
Likely bug 133904
And bug 134965 uses the same file, so maybe related too
You can replace delete crash for inserting rows until crash
File is based on attachment 161893 [details]
I see the bug in bibisect-linux-64-6.4 version newest. Alas, working in that repo on debian-buster, between old versions which run without crash and new versions which crash with the give STR, there is a long series of versions which crash upon opening the file. I am setting status NEW, but I am leaving keyword bibisectRequest in the hope that somebody else can get better results.
(In reply to Terrence Enger from comment #7) > I see the bug in bibisect-linux-64-6.4 version newest. Alas, working > in that repo on debian-buster, between old versions which run without > crash and new versions which crash with the give STR, there is a long > series of versions which crash upon opening the file. > > I am setting status NEW, but I am leaving keyword bibisectRequest in > the hope that somebody else can get better results. You're pretty experienced at bibisecting :-). So surely not convinced I can do better. A backtrace would be nice, though (adding Julien in addition; to compare who is faster ;-)
Created attachment 163534 [details] Bibisect log Bisected to author Michael Stahl <Michael.Stahl@cib.de> 2019-06-27 13:04:51 +0200 committer Michael Stahl <Michael.Stahl@cib.de> 2019-06-27 15:04:15 +0200 commit 1cb7e4899b5ada902e99a0c964ee047950c07044 (patch) tree b3db27ca9748967bb1b1d240965233842e1637d1 parent ef801197fcad9461390806a9fb42dd4566e55918 (diff) sw: avoid deleting the iterated SwRowFrame on tdf104188-4.odt The change in commit 1e6dec4b4313212a3bdc6bb06155fd65e795368b was not enough to fix this problem. SwContentFrame::CalcLowers() may move a SwTextFrame to the previous page; in that case Calc() on the upper is a bad idea because it may then call RemoveFollowFlowLine() and delete the SwRowFrame that is being iterated. There is one other (unknown) bugdoc with this problem, let's hope it's fixed as well... (regression from commit 18765b9fa739337d2d891513f6e2fb7c3ce23b50) STR 1. Delete all rows one by one until table gone 2. Press CTRL+Z until everything is back So I ignored crashes while pressing deleting rows https://cgit.freedesktop.org/libreoffice/core/commit/?id=1cb7e4899b5ada902e99a0c964ee047950c07044
Adding CC: to Michael Stahl
*** This bug has been marked as a duplicate of bug 133904 ***
(In reply to Telesto from comment #8) > A backtrace would be nice, though (adding Julien in addition; to compare who > is faster ;-) Funnily enough, I was already building the newest version which I expect to be able to run these STR. master refuses to delete table rows in a way which resulted in bug 135134. That one is not really the same; it is just what I bumped into as I was working up to the problem I hit with your file.
Created attachment 163539 [details] bt with debug symbols Here's a bt retrieved on pc Debian x86-64 with master sources updated today.