What happens: writer crashes every time What should happen: Writer should be nice and not crash :-) 1. Create a blank Writer document. 2. Create a table (I did 1 row x 2 columns) 3. Now, outside the table enter some text. 4. Select the text and add a comment to it. 5. Go back and select the table. Writer will crash. This happens in both 4.3 RC2 and 4.3 Beta 2. This does not happen in LO 4.2 so should be marked as a regression. Let me know if there are issues/queries. Steve.
no crash under Win7x64 using 4.4.0.0.alpha0+ Build ID: d5dd1216804afae35d7fe7dbb1d37b0ca1fcce88 TinderBox: Win-x86@39, Branch:master, Time: 2014-07-11_00:09:47 please define exact version of your Linux distro.
Linux is Ubuntu 14.04. I have installed the vanilla packages of LO 4.3.0.2 from the LO site. Regards, Steve
I have carried out the same on a Windows 8 machine using LO 4.3.0.2 and the same crash results. I have therefore updated the platform affected to All. A crucial detail that may not be fully apparent from the original method is that the comment seems to be need to be on a text range (so you need to select several characters and then add comment, a comment at a single point will not cause the crash). regards, Steve
@Steve please upload a test file where you reproduce the issue. if you stop your sequence at point 4, then save, close and reload the document, is the point 5 still a crasher?
@tommy27 Will attach sample file. Opening the sample file and selecting the table causes the crash for me. Regards, Steve
Created attachment 102853 [details] Sample file to cause crash Select the table in this sample file for Writer to crash (well, at least it does for me :-)
no crash under Win7x64 using 4.4.0.0.alpha0+ Build ID: d5dd1216804afae35d7fe7dbb1d37b0ca1fcce88 TinderBox: Win-x86@39, Branch:master, Time: 2014-07-11_00:09:47 I don't have 4.3.0.2 to test.
@tommy27 Version: 4.4.0.0.alpha0+ Build ID: 9ac24948d976ebc0565858e0ac4a6378165d532b TinderBox: Win-x86@51-TDF, Branch:MASTER, Time: 2014-07-15_22:56:14 Tried to reproduce on the above on Windows XP and I cannot reproduce either. So, seems to be just a 4.3 issue. Can someone else try on 4.3 and see if they can reproduce please? This is a serious show-stopping bug for me. Regards, Steve
Can't reproduce it, neither with the attached file nor with an own file. (But comment over text is always critical and causes sometimes unreproducible crashes) WIN 8.1 Version: 4.3.0.2 Build-ID: 14ed55896fdfcb93ff437b85c4f3e1923d2b1409
Hi, reproduced also with Version: 4.3.0.2 Build ID: 14ed55896fdfcb93ff437b85c4f3e1923d2b1409 Ubuntu 14.04 x64. The crash appears if you try to scroll the document after selecting the table. Text without comment don't crash. Reproduced with my own document and the sample provided. Set as New and Linux until confirmed under Win and Mac. Sophie
(In reply to comment #10) You are right: Scrolling is the problem. Crash with WIN 8.1 I get a Fatal Error with "SEH Exception: ACCESS VIOLATION"
@sophie @k-j Thank-you :-) Scrolling seems to be needed sometimes, but not always (at least for me). I seem to recall that's how I spotted it first, but subsequently I just needed to select the table and it crashed with no scrolling required. Regards, Steve.
Reproduced with Version: 4.3.0.0.beta1 Build-ID: b7cfa1eab1cb1e94f71d6df6612b73f231d0bf92 @ Win 7 and with 43daily Version: 4.3.1.0.0+ Build ID: 5d0673b0f9126f140ffc3d130ee3f04d4f8dcb07 TinderBox: Win-x86@42, Branch:libreoffice-4-3, Time: 2014-07-15_08:56:58 Working with: Version: 4.2.7.0.0+ Build ID: 0e3826d08d7a7d54dd532319fb584008eb0e24c8 TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2014-07-16_05:55:21 So REGRESSION between 4-2 and 4-3
SwSidebarWin::SetPosAndSize constructs a new shell cursor and calls FillRects() on it; the new cursor is not a table cursor, but SwShellCrsr::FillRects() queries the SwCrsrShell if it has a table selection, which is true, so subsequently we crash due to the assumption that the new cursor is a table cursor, on accessing non-existent SwCellFrm. it looks like this was fixed on master by commit 690c6787b4a2ab0118690fb8d00be871faa0db76 pushing that to 4.3 branch too... oops, forgot to add the bug id to the commit msg... on libreoffice-4-3 fixed by commit 3a2f00a90b5cc08c45cf92c82050247deb5176d6
Version: 4.3.1.0.0+ Build ID: 76a4eee58830b7faf4fa0a89e82df36e352d5b06 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-4-3, Time: 2014-07-18_03:04:45 I can no longer reproduce this in the above version, so all looks good. Should I change state to verified? Not sure of etiquette here. Thanks, Steve
yes, you could change it to VERIFIED. I leave the honour to you :-)