Created attachment 116585 [details] for testing Hi, I'm experiencing weird thing here. (see attachment) If you delete the column 'H', and then save. Nothing will happen, LibreOffice just blank or hangs. I tried with other office program, it's working fine. LibreOffice 4.4.3.2 Windows 7 64 bit
tested under Win8.1 x64 using LibO 4.4.3.2 I select the "H" column, right click and hit delete column LibO freezes for a few seconds then I get this error message: LibreOffice 4.4. - Fatal Error osl::Thread::create failed If I click OK LibO crashes tested with a recent LibO 5.1.0.0alpha LibO can't even load file I get this message error: The file 'test.ods' is corrupt and therefore cannot be opened. LibreOfficeDev can try to repair the file. The corruption could be the result of document manipulation or of structural document damage due to data transmission. We recommend that you do not trust the content of the repaired document. Execution of macros is disabled for this document. Should LibreOfficeDev repair the file? If I select YES, I got another error message: The file '$(ARG1)' could not be repaired and therefore cannot be opened. and fileopen aborts If I select NO I get this message: The file 'test.ods' could not be repaired and therefore cannot be opened. but instead the file is loaded and then I have the a longer freeze but no crash as in 4.4.3 if I click the save icon LibO freezes again then I see the same fatal error message and then it crashes
Please take a look in https://bugs.documentfoundation.org/show_bug.cgi?id=72470, maybe a dup.
Can't confirm the crash with any of the versions i've tested. And I can open the file normally. v4.4.4.1 under windows 7 x64. v4.4.3.2 under ubuntu 14.04 x64. v5.0.0.0 b3 under ubuntu 14.04 x64. When I delete the columns, there is a (big) freeze, but no crash. And if I close the file, the program freezes for a few secs.
Hi, just want to add a bit information. I just tried this problem in Google Docs. Works fine there too. So far it's only not working in LibreOffice for me. I think the bug's title is a bit wrong, I don't get crash after deleting column, I get blank/hang after attempting to save(see my first post).
behaviour seems different between Win8.1x64 and Win7x64 as said in comment 1 under Win8 I get a fatal error message and then crash after deleting "h" column now I'm on a Win7x64 machine with 4.4.3.2 and I can delete "h" column with transient freeze but no immediate crash... the crash happen as soon as I hit the "save" toolbar icon so I'm adjusting the summary notes again (feel free to edit yourself if you have a better summary) LibO 4.4.4.2 will be released soon, let's retest after it's available
(In reply to tommy27 from comment #5) > LibO 4.4.4.2 will be released soon, let's retest after it's available It's already available.
Still can't crash calc when pressing the save icon.
Created attachment 121502 [details] debug with LO 5.2alpha0 Crash on delete H column in Win7x64 reproduced from 4.2 to current 5.2alpha0. Fault Module Name in previous versions also MSVCR.. Problem Event Name: APPCRASH Application Name: soffice.bin Application Version: 5.0.4.2 Application Timestamp: 566ad0aa Fault Module Name: MSVCR120.dll Fault Module Version: 12.0.21005.1 Fault Module Timestamp: 524f7ce6 Exception Code: 40000015 Exception Offset: 000a7676 OS Version: 6.1.7601.2.1.0.256.48 Locale ID: 4122 But later on not reproduced again. Not sure about the regression, I'll let someone decide on bibisect request. Fileopen problem from Comment 1 not reproduced.
As per today, this regression can't be bibisected as it was introduced before 4.4 branch and there's no bibisect repository for the affected branch for windows, thus change 'bibisectRequest' to 'preBibisect'.
Please test with current master and upcoming 5.1.6 (5-1 branch) and 5.2.2 (5-2 branch), if not reproducible there then close this bug.
Created attachment 127431 [details] debug with LO 5.3alpha0 via procdump Bug still reproducible with the current master.
I can reproduce this on delete under 32bit windws In ScDocFunc::DeleteCells at line 2340 I see a qDecreaseRange with 5579 entries in it There is a gadzillion UnmergeCells calls, and each one will create a new undo doc In my case on iteration 5122 through the qDecreaseRange I run out of memory and get a std::exception
Urgh.. investigating.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=647e860435c781fbb111ae59bc70dc8e6776fed5 Resolves: tdf#92117 create only one Undo for all UnmergeCells() calls It will be available in 5.3.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 "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0ebe9fab18e732468d2b9d53dddf9f266411a0e5 init ScUndoRemoveMerge with range, tdf#92117 follow-up It will be available in 5.3.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.
Pending review https://gerrit.libreoffice.org/30297 for 5-2
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=cd998b587f9956c1f4292d4db3200cc6c9320001&h=libreoffice-5-2 Resolves: tdf#92117 create only one Undo for all UnmergeCells() calls It will be available in 5.2.4. 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.