Steps to reproduce:
1. New Calc, type "1" in A1;
2. Ctrl+A to select the whole sheet, then Ctrl+C to copy.
3. New "sheet2", Ctrl+V to paste;
Calc hangs at step 4.
Calc should successfully undo at step 4 without hang.
Copy/paste only cell A1 works as expected.
Build ID: 7d55112667c8fcddb67bc3803796b46c93aa56b0
Also reproducible on master with lo-linux-dbgutil-daily updated today.
reproducible under Win7x64 with LibO 4.4.0 recent daily buil, 4.3.2 and 4.2.1
works fine in 4.2.0, hence regression of the 4.2.x branch between .0 and .1 release.
May be caused by the fix of:
Bug 74014 - Editing: Cell formula not updating on redo, even with a forced recalculation
(As tommy pointed out, this bug is between 188.8.131.52 and 184.108.40.206. The fix of bug 74014 was target:4.2.1)
Adding Kohei Yoshida to CC list.
No crash with Version: 220.127.116.11.alpha1+
Build ID: 04ea7b24ec1b5a027efa0b850f2bc3ac7116c52e
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-11-06_00:02:40
After undo LO freeze for ~30 sec (100%CPU), but no crash.
e2ef0c10eb06304986b8503584b44f02561ce4b5 is the first bad commit
Author: Bjoern Michaelsen <firstname.lastname@example.org>
Date: Sun May 11 07:43:35 2014 +0000
Author: Miklos Vajna <email@example.com>
AuthorDate: Wed Jan 29 22:33:58 2014 +0100
Commit: Miklos Vajna <firstname.lastname@example.org>
CommitDate: Wed Jan 29 22:39:10 2014 +0100
writerfilter: these SPRM's are unused
:100644 100644 465b41ea445be5b02f860c48c3f9f0218a7c857a 85f45f30feba11075310aa745a053a971ef1fec8 M ccache.log
:100644 100644 8bd9bbb15f6d30a5cd2a8bba9e61df8fe802c833 470744529aea69fd6c7e11bfeb8a617a44cce560 M commitmsg
:100644 100644 c70aaedacb567416d594b8e1bb16eed65d5990fd 73be70ccec187662ed9baac45a515c87da03aad6 M make.log
:040000 040000 5479cfabe7b8a2c8a120caea61a83bc702475091 5566567c915a96b69c2ff95753bdf3730a195b70 M opt
# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# good: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect good e02439a3d6297a1f5334fa558ddec5ef4212c574
# good: [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b
git bisect good 4850941efe43ae800be5c76e1102ab80ac2c085d
# bad: [a900e72b6357882284c5955bdf939bf14269f5fb] source-hash-dd1050b182260a26a1d0ba6d0ef3a6fecc3f4e07
git bisect bad a900e72b6357882284c5955bdf939bf14269f5fb
# bad: [e1d0365cd2b073a859f59ad0a4584385a66dc611] source-hash-2eea96c702a44ab009743b0d22ef639127f0b57b
git bisect bad e1d0365cd2b073a859f59ad0a4584385a66dc611
# good: [98a55bf95f3ec29298751fd8fba76dd2236dce43] source-hash-58dfc97ca697875c36b7ddf14f5505a93d7b9cf8
git bisect good 98a55bf95f3ec29298751fd8fba76dd2236dce43
# bad: [1f32fb58159d7f43a4bcb838765261d5274cbf38] source-hash-4a169e4203c10ec8f76b9bcb33882c82b65c7bab
git bisect bad 1f32fb58159d7f43a4bcb838765261d5274cbf38
# good: [2a073e18fe4a9176dd35e962655ebf05a1e8d1b9] source-hash-4e938c468a1d1b6e93a4e468bbfe2f4270e37c4b
git bisect good 2a073e18fe4a9176dd35e962655ebf05a1e8d1b9
# bad: [e2ef0c10eb06304986b8503584b44f02561ce4b5] source-hash-1b4aadebeb1898686313ff30ef47ddc4336a7444
git bisect bad e2ef0c10eb06304986b8503584b44f02561ce4b5
# good: [78299d579aaf6b0419b99bb858a7af62d1f4d3dc] source-hash-218c9cff53c36d3f6e744067d5812b883a60b459
git bisect good 78299d579aaf6b0419b99bb858a7af62d1f4d3dc
# first bad commit: [e2ef0c10eb06304986b8503584b44f02561ce4b5] source-hash-1b4aadebeb1898686313ff30ef47ddc4336a7444
Changing keywords back - not (yet) bisected, just bibisected
(Commented during a sweep of bugs that are bibisected but not source bisected)
Building the source in the range of the bibisect didn't yield a working binary, but based on the commits in the range, it seems very likely that this one is related:
Author: Kohei Yoshida <email@example.com>
Date: Wed Jan 29 14:00:47 2014 -0500
fdo#74014: Broadcast changes during undo and redo after paste.
*** Bug 89938 has been marked as a duplicate of this bug. ***
According to bug prioritization flowchart, I'm marking this up to at least "High" importance
Can't reproduce with LO 18.104.22.168 on Linux. It doesn't crash, just the undo is very fscking slow.
I'm able to reproduce this with 22.214.171.124, but can't reproduce this using 126.96.36.199, 188.8.131.52, or last night's nightly. I also don't see any of the hesitation reported in comment 9 in these versions.
So, I believe this was fixed at some point. If someone else wants to confirm that it's fixed, it should probably be marked RESOLVED:WORKSFORME since we don't know which patch fixed it.
(In reply to tmacalp from comment #10)
> I'm able to reproduce this with 184.108.40.206, but can't reproduce this using
> 220.127.116.11, 18.104.22.168, or last night's nightly. I also don't see any of the
> hesitation reported in comment 9 in these versions.
I think your confirmation is enough to label it as WFM
Migrating Whiteboard tags to Keywords: (bibisected)