This bug was filed from the crash reporting server and is br-3c18620f-0706-4bc3-8436-1604899e8a85. ========================================= Pretty similar to bug 119125 1. Open attachment 143995 [details] 2. Press CTRL+A in Cell A1 3. CTRL+C 4. Paste somewhere at the yellow marking on the second page (will move up to the first when clicking) 5. CTRL+V 6. Page scrolls down 7. Scroll up again to the initial pasting point (using the drag slider at the right or the scroll wheel or a combination).. it will crash in 1/4 or so 8. It certainly crashes when pasting the same content at the same place again (again with a different trace) Different crash with similar steps: http://crashreport.libreoffice.org/stats/crash_details/74a1161a-320c-4e59-bef7-661282713c13
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=b4b5dbee1ec7770ed64d7270de46d5cfc06b87b6 author Miklos Vajna <vmiklos@collabora.co.uk> 2016-03-23 16:44:43 +0100 committer Miklos Vajna <vmiklos@collabora.co.uk> 2016-03-23 16:36:48 +0000 commit b4b5dbee1ec7770ed64d7270de46d5cfc06b87b6 (patch) tree 861f662a721df5bd3f6a2569db0d3ae49864972f parent 11231f9179db9821effc884e8adade48fdf89938 (diff) tdf#88453 sw layout: fix split of nested tables with large amount of rows Bisected with: bibisect-linux-64-5.2 Adding Cc: to Miklos Vajna
Adding Cc: to Miklos Vajna
*** Bug 119125 has been marked as a duplicate of this bug. ***
Created attachment 144071 [details] gdb bt On pc Debian x86-64 with master sources updated today, I got a crash before pasting.
*** Bug 119108 has been marked as a duplicate of this bug. ***
Is this reproducible now that bug 117086 is fixed?
(In reply to Miklos Vajna from comment #6) > Is this reproducible now that bug 117086 is fixed? Yep, still reproducible in Version: 6.2.0.0.alpha0+ Build ID: 1af7f19224f18e5025352339648db659575eae33 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: threaded
Bug 116293 might be related to. Compare BT comment 4 & bug 116293 comment 12
(In reply to Xisco Faulí from comment #7) > Yep, still reproducible OK, thanks. One can dream... :-)
Created attachment 147138 [details] sample file in sigle page view I found it's easier to reproduce with a single page view... Steps: 1. Open attached file 2. Put cursor in cell A1 3. Copy 4. Scroll to page 2, put the cursor after the yellow mark, and paste -> CRASH
Is there any step between 2. and 3.? Like "select all"? If you just put the cursor somewhere and hit copy, I don't think anything happens.
Created attachment 147139 [details] gdb backtrace
Steps: 1. Open attached file 2. Put cursor in cell A1 3. Select All 4. Copy 5. Scroll to page 2, put the cursor after the yellow mark, and paste -> CRASH
I assume the correct crash signature for this crash is http://crashreport.libreoffice.org/stats/crash_details/2fe96f40-a9ea-4a78-86eb-63a8428d520e
Increasing severity taking into account the number of crashes in the crashreport service
Just to be sure, I reverted b4b5dbee1ec7770ed64d7270de46d5cfc06b87b6 locally and the crash from comment 13 is not reproducible...
So I took a stab at this, and I wonder perhaps this is already fixed by 0005b330eaed0b5559042d2597fb45e0c9125d7e (forcepoint#76 avoid deleting footnote that would delete undeletable page, 2018-12-05)? Here is what I tried: - the bug document and repro steps were hard for me from this bug, I could not work out a way to reliably trigger the crash - I went over to bug 119125, which is a duplicate of this bug, and there the following repro steps always happened to me: 1) open the bugdoc 2) go to A1 3) Ctlr-A 4) Ctrl-C 5) Go to after "xx" in the yellow "xxxx" (middle of it) 6) paste 7) Go to after "x" in the first yellow "xx" (middle of it) 8) paste -> wait -> should crash I noticed that (guessing based on the date of the last comment of this bug) bibisect-linux-64-6.3 commit 483a135e crashes reliably this way, but not bibisect-linux-64-6.3 master. So I reverse bisected what commit fixed this scenario and found the above commit. All in all: should this be closed, knowing that the above commit is already in master and libreoffice-6-2? Or all what's left is to cherry-pick that further to libreoffice-6-1?
I'm still able the produce crashes with the document, but without clear reliable steps.. Version: 6.3.0.0.alpha0+ Build ID: 61778fd20395794d2de3b52d60dcc65083aecd93 CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL also the backtrace seems different
Indeed, it's fixed in Versión: 6.2.0.2 Id. de compilación: 2ce5217b30a543f7666022df50f0562f82be0cff Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; VCL: win; Configuración regional: es-ES (es_ES); Idioma de IU: es-ES Calc: threaded and Version: 6.3.0.0.alpha0+ Build ID: cec7ae9f3c69ecc83462f28fc4987e37dc1b420e CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded if steps from comment 13 are followed. Closing as RESOLVED WORKSFORME @Telesto, Please report a follow-up bug if you find new reliable steps to reproduce a crash!
(In reply to Miklos Vajna from comment #17) > So I took a stab at this, and I wonder perhaps this is already fixed by > 0005b330eaed0b5559042d2597fb45e0c9125d7e (forcepoint#76 avoid deleting > footnote that would delete undeletable page, 2018-12-05)? I do confirm my steps from comment 13 are fixed by 0005b330eaed0b5559042d2597fb45e0c9125d7e
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-1": https://git.libreoffice.org/core/+/558f01a29cb640760e73724f6efdc0a1be20c8e3%5E%21 tdf#119126 forcepoint#76 avoid deleting footnote that would delete ... It will be available in 6.1.5. 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.