Created attachment 90347 [details] spreadsheet that will crash on filesave after modifying one cell content Hello, OS : Windows Vista Pro 32bits + SP2 on 4.0.6.2 at work, I switched to 4.1.3.2 (release) (through software removal and then installing the new version). I then had to go back to previous version because calc would systematically crash on filesave with certain files, which is a blocker for me. With the file attached (no confidential job data in it) I could reproduce the bug easily : * I open the file with calc 4.1.3.2 * I enter a "1" in the J182 cell on the first sheet from the left ("congés") * I then try to save the file * I see the progress bar and suddenly calc crashes. This does not happen with v4.0.6.2. I don't know if it can be related to bug #71847. Thanks, -- Chris
Hi Chris, Thanks for your report & the file. It does not crash for me in 4.1.3.2 and 4.2.0beta1 on Linux (Ubuntu). Have you tried with a clean user profile? http://wiki.documentfoundation.org/UserProfile Or could it be Windows-specific? Best, Cor
(In reply to comment #1) > Have you tried with a clean user profile? Hi Cor, thanks for your interest. I took my work laptop to home for the week-end, to be able to do some tests. I've removed 4.0.2 and installed back 4.1.3.2 (using it in French, along with the 4.1.3 helppack_fr). I've first checked the file : first time, it did not crash on saving. Then after closing it and re-opening it, it then crashed on saving it. Doing copies of the file, working on them : a few times it did not crash on the first edition, I had to close the file and re-open it to get the bug to appear. But once it has crashed once, it seems to crash systematically. I've tried with a clean user profile as you've asked (moving %appdata%/Roaming/LibreOffice/4/user to user-old). On launching LibreOffice the folder was re-created. The bug is still present with the new profile. I will join the new version (travail2.ods) of the file I used to do these tests. I've changed the status of the bug back to unconfirmed, as what's seems logic to me (needinfo -> I give info -> unconfirmed -> another cycle). Sorry if that's not what should be done, that's my first bug filing on this platform and I've not found help on the "needinfo" tag in the bugzilla user's guide on the site.
Created attachment 90364 [details] 2nd version of the file
So I confirm it using version Version: 4.1.3.2 Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a and FR langpack under Ubuntu 13.10. I modified one cell in Congé Payé, then save, then crash. I'll try to provide a bt of the crash - Change Plateform and set to New - Sophie
Created attachment 90367 [details] backtrace of the crash Hope it is complete - Sophie
(In reply to comment #4) > So I confirm it using version Version: 4.1.3.2 > Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a and FR langpack under > Ubuntu 13.10. I modified one cell in Congé Payé, then save, then crash. I'll > try to provide a bt of the crash - Change Plateform and set to New - Sophie Hi Sophie, I confirm that my report of the bug was made on the exact same version and build (70feb....57a) of LO, with FR langpack, on Windows Vista Professional SP2 32 bits. Thanks, -- Chris
I tested with Version: 4.2.0.0.beta2 Build ID: 1a27be92e320f97c20d581a69ef1c8b99ea9885d no langpack install so default en_US and also in Options > Language Settings > Language > Locale settings > English (US). And I've the same crash each time. So I don't think finally that FR is involved in the crash. If a back trace is needed for 4.2.0beta2, just tell me :) - Sophie
Crash reproducible for me with version 4.2.0.0.beta2+ (Build ID: a125b9da3035a584ffd2203f2b3c71c972b8bd4c) and version 4.1.5.0+ under Ubuntu 13.10 x86-64. No crash with version 4.0.6 Crash --> set severity to critical Set CRASH at the beginning of the summary as, there, it is more important than filesave. Best regards. JBF
The crash seems to have something to do with the formatting of column B. Try that: click on the header of the column to select the entire column, then press ctrl+M to remove all manual formatting (don't worry with the loss of date formatting), then ctrl+S. Most of the time, it works for me. Yes, most of the time but not always. If it works you can restore the date formatting and it continues to works. Best regards. JBF
(In reply to comment #9) > The crash seems to have something to do with the formatting of column B. > Try that: click on the header of the column to select the entire column, > then press ctrl+M to remove all manual formatting (don't worry with the loss > of date formatting), then ctrl+S. Most of the time, it works for me. Yes, > most of the time but not always. If it works you can restore the date > formatting and it continues to works. > > Best regards. JBF Hello JB, thanks for the tip. Unfortunately, I've tried it several times : most of the times it does not work for me, removing the manual format on column B does not solve the crashing issue. Sometimes though I'm able to save without a crash, maybe 1 in 10 times I would say. I've also tried removing the manual formatting on all the cells of the sheet (Ctrl+a ctrl+m), with the same unfortunate result. Don't know if there can be a timing issue or an uninitialized value problem, because what's weird is that sometimes, doing the exact same manipulations, the file saves without crashing... Thanks and Best Regards, -- Chris
warn:legacy.osl:32673:1:sc/source/filter/xml/XMLStylesExportHelper.cxx:1080: wrong table /usr/include/c++/4.8.2/debug/vector:346:error: attempt to subscript container with out-of-bounds index 2, but container only holds 2 elements. Objects involved in the operation: sequence "this" @ 0x0x5ddd7e0 { type = NSt7__debug6vectorINS0_I13ScColumnStyleSaIS1_EEESaIS3_EEE; }
I'm curious. Does the same step also crash when using either very old OOo or AOO? The problem code appears to be from the OOo code, but it's also possible that some of our (many) changes on top have caused this as well. It's not clear which is the case...
I'm taking this in the meantime.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5000e64ecc55efd47d92714cf6db375ff37aac4b fdo#72390: Let's not skip auto styles from unmodified sheets. 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.
Backport requests on gerrit: 4.2: https://gerrit.libreoffice.org/8049 4.2.1: https://gerrit.libreoffice.org/8050 4.1: https://gerrit.libreoffice.org/8051
(In reply to comment #12) > I'm curious. Does the same step also crash when using either very old OOo or > AOO? > > The problem code appears to be from the OOo code, but it's also possible > that some of our (many) changes on top have caused this as well. It's not > clear which is the case... Hello, I can confirm that this bug does not appear with this exact file on LO 3.5.X (on Debian Wheezy 64 bits) and 4.0.x (o Windows Vista Pro 32 bits) versions. Regarding previous versions and OOo versions, I can not be absolutely sure, but I'm using the same template since mid-2006, obviously with different values each year. During this time I've been through all versions of OOo since 2.1.x and following, and then with all version of LO since it launches, and I've never bumped into this bug. For what it's worth... Thanks.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0779d3efc97a985eeedf2a45bac11afe5b11b516&h=libreoffice-4-2 fdo#72390: Let's not skip auto styles from unmodified sheets. It will be available in LibreOffice 4.2.2. 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.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "libreoffice-4-2-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a8a4d42c15f38ed7c8595179263239f9e8b7824f&h=libreoffice-4-2-1 fdo#72390: Let's not skip auto styles from unmodified sheets. It will be available already in LibreOffice 4.2.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.
Fixed.
correcting target, since 4.2.1.1 is 4.2.1 release
Kohei Yoshida committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b6df2950db8394e6bd73fe708dbc20f3d8f4e5c2&h=libreoffice-4-1 fdo#72390: Let's not skip auto styles from unmodified sheets. It will be available in LibreOffice 4.1.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.
Hi, I've initially reported the bug. I've just made a new test with version 4.2.2 RC1 2014-03-05 (about LibreOffice : Version 4.2.2.1, Build ID : 3be8cda0bddd8e430d8cda1ebfd581265cca5a0f), and this time I was not able to make the bug occur. I can now confirm that Kohei's patch seems to have solved the problem for me. Thanks Kohei !