Created attachment 134102 [details] zip-File with 2 spreadsheets to reproduce resp. demonstrate the error When cells with comment are copied via copy + paste, only the comment box of first copied cell is pasted with correct position and dimension. From the second time on dimensions and position of comment boxes are lost at copy + paste. Reproducing the the error: - open file "Test_Comment_V2.ods" from the attached zip file - copy cell A4 into the clipboard - paste it into cell E4 (and into cell I4 etc.) -> Result: comment boxes are pasted with correct position and dimensions - copy cell A10 (or cell A4 a second time) into the clipboard - paste it into cell E10 (and into cell I10 etc.) -> Result: comment boxes are pasted with wrong position and dimensions (see file "Test_Comment_V2_edited.ods" in the zip-file) Error reproduced also with Version: 5.3.4.2 (x64) and with Version: 6.0.0.0.alpha0+ (x64) Build ID: d6c4c576ef71f2294ec8eefc6576a797220e6809 CPU threads: 2; OS: Windows 6.19; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2017-06-18_00:32:25 Locale: de-DE (de_DE); Calc: group
I got different results: I got the wrong position after pasting to I*. When I copied A10, it "reset" and only paste to I10 was wrong. Yet: no problems at all in 3.6. Arch Linux 64-bit, KDE Plasma 5 Version: 6.0.0.0.alpha0+ Build ID: f808c50c6eece87d515df3b84b1c774395b5d9bc CPU threads: 8; OS: Linux 4.11; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on June 26th 2017 Arch Linux 64-bit Version 3.6.7.2 (Build ID: e183d5b)
no repro. Version: 6.0.0.0.alpha0+ Build ID: 643da8ec4e721d33dfdf8d78bedd50a915f1188d CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-06-26_01:29:47
Created attachment 134320 [details] Screenshots of tests with LO 6.0 in Win10 and with LO 5.3.3 in Ubuntu Maybe the bug exists only in Windows. I can reproduce the bug with the (nearly) newest builds of LO 6.0 in Win 10 (build 15063.413 64 bit, preview build 16226 32 bit and 64 bit), but not with LO 5.3.3 in Ubuntu, see screenshots in attached archive file "Screenshots_Bug_108612.tar.gz"!
(In reply to Stefan_Lange_KA@T-Online.de from comment #3) > Created attachment 134320 [details] > Screenshots of tests with LO 6.0 in Win10 and with LO 5.3.3 in Ubuntu > > Maybe the bug exists only in Windows. I can reproduce the bug with the > (nearly) newest builds of LO 6.0 in Win 10 (build 15063.413 64 bit, preview > build 16226 32 bit and 64 bit), but not with LO 5.3.3 in Ubuntu, see > screenshots in attached archive file "Screenshots_Bug_108612.tar.gz"! No, as I said in my comment 1 I am seeing the problem on Linux, but only with slightly different results/steps.
This seems to have begun at the below commit. Adding Cc: to Eike Rathke; Could you possibly take a look at this one? Thanks a3a754ba53116b1ed03ad493908db89e1d636451 is the first bad commit commit a3a754ba53116b1ed03ad493908db89e1d636451 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Fri Feb 10 22:00:08 2017 -0800 source cb566c056b0e8f9f73dac3cbaf497e102a247cb9 author Eike Rathke <erack@redhat.com> 2017-01-18 15:18:38 (GMT) committer Eike Rathke <erack@redhat.com> 2017-01-18 15:19:09 (GMT) commit cb566c056b0e8f9f73dac3cbaf497e102a247cb9 (patch) tree 93ba07dd11cab7ef22778971959de3bc7694ee1d parent 2fb220093f7178f75ebd582bbcd956c1ee7e03db (diff) tdf#104967 prevent crash when pasting notes originating from a closed document This is only a workaround to prevent a crash, the actual note content is lost when pasting, only a standard empty note caption will be pasted.
(In reply to raal from comment #5) > This seems to have begun at the below commit. I doubt that. That code is executed only when closing a document that is the clipboard source to forget the caption pointers pointing into that document's drawing layer. The bug description doesn't involve closing the document.
Fwiw, I can not reproduce (on Linux) in any version, 5.3.3, 5.3.4, >=5.4.0.beta2 or master.
Created attachment 134462 [details] Valgrind log from master This is a log of copying A4 and pasting to E4 and then to I4. Arch Linux 64-bit, KDE Plasma 5 Version: 6.0.0.0.alpha0+ Build ID: 98befbb26217b0bf3f35354e418a355280c52cfc CPU threads: 8; OS: Linux 4.11; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on June 29th 2017
Does the log for copying A10 and pasting to E10, I10 differ in anything relevant for this case?
Created attachment 134465 [details] Valgrind log from master, A10 as the source of copying
Nothing suspicious so far. With the commit Raal identified and a screenshot he sent me, I suspect that under some unknown circumstances ScDocument::IsClipboardSource() returns true when it should not (which is the only possibility where the identified commit comes into play). There is one step in the reproduction scenario, copying A10 to the clipboard when A4 was already copied, where the first clipboard document is destroyed and ScDocument::IsClipboardSource() is called. Now, if someone who can reproduce the bug and has debug capabilities could set a breakpoint in sc/source/core/data/documen2.cxx ScDocument::~ScDocument() on the call to IsClipboardSource(), then after having copied A4 already when copying A10 into the clipboard the breakpoint should be hit. Stepping into IsClipboardSource() it should not return true, but if it does it would be good to know why and what made it think it should..
Further thinking: if so that probably would involve that ScModule::GetClipDoc() returns a document that is not the actual clipboard document but an ordinary one, most likely the source document itself, which would be even weirder..
Ok, I launched LibO and then in a terminal sudo gdb --pid `pgrep soffice` I let it attach and then in the (gdb) prompt gave break documen2.cxx:385 ie. this line: https://cgit.freedesktop.org/libreoffice/core/tree/sc/source/core/data/documen2.cxx#n385 Then I gave c to continue. The breakpoint is hit the first time already when I pasted A4 to E4. I continued and this is what I got when copying A10: Thread 1 "soffice.bin" hit Breakpoint 1, ScDocument::~ScDocument (this=0x6a45170, __in_chrg=<optimized out>) at /home/user/libreoffice/sc/source/core/data/documen2.cxx:385 385 if (IsClipboardSource()) (gdb) step ScDocument::IsClipboardSource (this=this@entry=0x6a45170) at /home/user/libreoffice/sc/source/core/data/document.cxx:2544 2544 { It was a bit disturbing along the way that gdb grabbed my mouse click focus. I managed to solve it with this: https://unix.stackexchange.com/a/40472
I checked with Áron and he asked me to use next instead of step. This is with copying A10 while A4 is already in the clipboard: 385 if (IsClipboardSource()) (gdb) n 397 mxFormulaParserPool.reset(); (gdb) n 400 pExternalRefMgr.reset(); (gdb) n 402 ScAddInAsync::RemoveDocument( this ); So I understand the if is evaluated to false.
Stefan: if you would like to try what result you get (as I had different symptoms): Install gdb Launch LibreOffice from the commandline with SAL_NO_MOUSEGRABS=1 ./soffice That way your mouse clicks will not be hijacked. Then attach gdb to LibreOffice: sudo gdb --pid `pgrep soffice` Press enter when it asks. When you see the (gdb) prompt, give the command break documen2.cxx:385 Then give the command: c Then start doing the reproduction steps in LibreOffice. Use c in gdb to continue until before you have copied A10 to clipboard. When it breaks the next time, give the command n (for next) like in my previous comment. Then you can show us your results.
Created attachment 134505 [details] Log of terminal and gdb from the test Buovjaga, I have tried to make what you have written, but I had some problems, see also attached log in the odt document! First problem is: (gdb) break documen2.cxx:385 No source file named documen2.cxx. Make breakpoint pending on future shared library load? (y or [n]) y Must be available for the test the source documen2.cxx:385? When yes, where must it be located? Second problem: In the test didn't come a break, not at first copy + paste and not at second. I don't know if the reason is the missing (or wrongly located) source or is it the fact that I can't reproduce the error in Linuy (Ubuntu 17.04) - see my Comment 3. PS: I am a beginner in Ubuntu and I'm not very familiar with this system.
Ok, you could first install the debug package: sudo apt-get install libreoffice-dbg Note that it is over 2,5 gigabytes.
Created attachment 134511 [details] Log of terminal from install libreoffice-dbg I couldn't install libreoffice-dbg because of errors, see attached log. Maybe version conflicts?
(In reply to Stefan_Lange_KA@T-Online.de from comment #18) > I couldn't install libreoffice-dbg because of errors, see attached log. > Maybe version conflicts? Your system pulls in a way too old libreoffice-dbg version 4.2.8, make sure your dbg package repository matches the release of your regular package repository, or wherever you installed LO 5.3.3 from.
(In reply to Buovjaga from comment #15) > Then attach gdb to LibreOffice: > sudo gdb --pid `pgrep soffice` Don't use sudo ...
(In reply to Eike Rathke from comment #20) > (In reply to Buovjaga from comment #15) > > Then attach gdb to LibreOffice: > > sudo gdb --pid `pgrep soffice` > Don't use sudo ... I have to personally. If I don't, it says: ptrace: Operation not permitted. This is because of https://wiki.archlinux.org/index.php/security#ptrace_scope
So the debugger then can wipe the entire system, great security feature ;-) SCNR.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d5020f35aec54f0241fa58557dc6caadc149f5a9 Attempt to blind fix tdf#108612 explicitly checking for clipboard document It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
If someone who could originally reproduce could please check with one of the next master builds that includes the above commit if that fixes the problem? Thanks.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=432f766892478f4693ca830e7d07bd195637fae0 Assert that GetClipDoc() is indeed a clipboard document, tdf#108612 related It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 134545 [details] Screenshot from my test The error still occurs with Version: 6.0.0.0.alpha0+ (x64) Build ID: 7b4f4f15971047664fa278fff96b959d53b272b3 CPU threads: 2; OS: Windows 6.19; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2017-07-08_01:39:24 Locale: de-DE (de_DE); Calc: group
Yep, I am still seeing my own variation of the issue. Arch Linux 64-bit, KDE Plasma 5 Version: 6.0.0.0.alpha0+ Build ID: b91cb7d137b5d8fd203bbdc1c4e3d0e851fd5aa6 CPU threads: 8; OS: Linux 4.11; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on July 9th 2017
I can repro this as well (build from 07-07), and can debug into the mentioned code, but I'm not sure what I should be looking for. Is there a way to identify what ScModule::GetClipDoc() returns? I can see that aDocName is "Test_Comment_V2". bIsClip is true, so it passes the assert.
(In reply to Aron Budea from comment #28) > I can see > that aDocName is "Test_Comment_V2". bIsClip is true, so it passes the assert. You mean at the pDoc within ScModule::GetClipDoc()? On whic platform? When? On the first copy? Or the second copy? The weird thing is that on Linux the ScTransferObj::GetOwnClipboard() already returns nullptr for me so there's never a clipboard doc in this scenario until the original is closed after something was copied to the clipboard.
(In reply to Eike Rathke from comment #29) > You mean at the pDoc within ScModule::GetClipDoc()? On whic platform? When? > On the first copy? Or the second copy? The weird thing is that on Linux the > ScTransferObj::GetOwnClipboard() already returns nullptr for me so there's > never a clipboard doc in this scenario until the original is closed after > something was copied to the clipboard. Yes. On Windows 7, during second copy. Would the normal behavior be to return nullptr as it happens for you on Linux?
Hard to say, the current ScTransferObj should had been released already, but it is a weak reference and maybe things differ in detail. However, what actually is important that the only ScDocument destroyed is the then current clipboard document when copying the second cell. The ScDocument::IsClipboardSource() called from there must return false. Could you do me a favour and check if there in ScDocument::IsClipboardSource() pClipDoc==this and/or both, pClipDoc->bIsClip and this->bIsClip are true?
(In reply to Eike Rathke from comment #31) > Hard to say, the current ScTransferObj should had been released already, but > it is a weak reference and maybe things differ in detail. However, what > actually is important that the only ScDocument destroyed is the then current > clipboard document when copying the second cell. The > ScDocument::IsClipboardSource() called from there must return false. > > Could you do me a favour and check if there in > ScDocument::IsClipboardSource() pClipDoc==this and/or both, > pClipDoc->bIsClip and this->bIsClip are true? During second copy to clipboard, right? 1. pClipDoc and this are different. 2. pClipDoc->bIsClip is true, this->bIsClip is also true.
(In reply to Aron Budea from comment #32) > During second copy to clipboard, right? Correct. > 1. pClipDoc and this are different. > 2. pClipDoc->bIsClip is true, > this->bIsClip is also true. That's completely odd, but confirms my suspicion. Thanks.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=52e09f2c03f7cc024b2973c4806283c324fc23df Another attempt to blind fix tdf#108612 It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hopefully that will do.. If you could please check with one of the next master builds that includes the above commit if that fixes the problem? Thanks.
(In reply to Eike Rathke from comment #35) > Hopefully that will do.. > If you could please check with one of the next master builds that includes > the above commit if that fixes the problem? Thanks. I confirm that "my version" of the problem is gone! Arch Linux 64-bit, KDE Plasma 5 Version: 6.0.0.0.alpha0+ Build ID: 8d4d1e8d1cd4b400bc395dcbb98fb1e82eaf4e0f CPU threads: 8; OS: Linux 4.11; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on July 20th 2017
Great, Thanks! Pending review https://gerrit.libreoffice.org/40249 for 5-4 https://gerrit.libreoffice.org/40251 for 5-3 https://gerrit.libreoffice.org/40250 for 5-4-0 https://gerrit.libreoffice.org/40252 for 5-3-5
Btw, do people who could reproduce this also run some "clipboard enhancer", multiple clipboard manager or such thing?
(In reply to Eike Rathke from comment #38) > Btw, do people who could reproduce this also run some "clipboard enhancer", > multiple clipboard manager or such thing? Looks fixed here as well, and no, I'm not using any kind of clipboard manager.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-5-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3c4b67ac73aae4f44938c296d1a54ff68c6e2ae8&h=libreoffice-5-4 Blind fix tdf#108612 explicitly checking for and against clipboard document It will be available in 5.4.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c5917736e39ff1e5d6995f93e9108082a87d9e35&h=libreoffice-5-3 Blind fix tdf#108612 explicitly checking for and against clipboard document It will be available in 5.3.6. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Test was OK with Version: 6.0.0.0.alpha0+ Build ID: a9588baca8137f51e2ca72e40b1f448b0e1885d1 CPU threads: 1; OS: Windows 6.19; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-07-21_02:58:26 Locale: de-DE (de_DE); Calc: group and with Version: 6.0.0.0.alpha0+ (x64) Build ID: a9588baca8137f51e2ca72e40b1f448b0e1885d1 CPU threads: 2; OS: Windows 6.19; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2017-07-21_04:09:11 Locale: de-DE (de_DE); Calc: group I have also made a test with activated "Cipboarder" (Multi clipboard manager from "8GadgetPack" for Windows 8): When cells are copied directly via copy + paste, they are pasted correctly, but when the are selected for paste in "Cliboarder", only cell contents is - not correctly - pasted. Seems that in "Clipboarder" are saved for paste not all attributes of Calc cells.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-5-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5fb6e24496a925eafe91b337ab4e8ae6a4ed8900&h=libreoffice-5-4-0 Blind fix tdf#108612 explicitly checking for and against clipboard document It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-5-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=54db051a7224f053502d5be14ba512837d11b70e&h=libreoffice-5-3-5 Blind fix tdf#108612 explicitly checking for and against clipboard document It will be available in 5.3.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Test with Version: 5.3.5.2 (x64) Build-ID: 50d9bf2b0a79cdb85a3814b592608037a682059d CPU-Threads: 4; Betriebssystem:Windows 6.19; UI-Render: GL; Layout Engine: new; Gebietsschema: de-DE (de_DE); Calc: CL was OK!
Great, let's set to verified, then.