Created attachment 49440 [details] sample file to demonstrate data corruption Bring up the attached spreadsheet in LibreOffice. Pay careful attention to the area of the spreadsheet around "MT" and "Defenses". This area is where you will see the problem. Bring up the defined names panel at Insert->Names->Define. Select the defined name EditionPowers. Change the end of the range from row 113 to row 116. Click Modify, then click OK. Quit LibreOffice. Click Save when it asks to save your changes. Bring up the spreadsheet again. You will see the corrupted cells in the aforementioned area.
Effect is [Reproducible] with "LibreOffice 3.4.1 RC2 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:202)]" and reporter's sample. After Reopen lots of error contents "#NAME?". The operation to modify the name range might simply be a forbidden bad action? Indications: - OOo3.1.1 does not show the problem ? LibO 3.3.3 Portable does not show the problem, so it seems to be a REGRESSION - OOo-dev 3.4 does not show the problem - Master does not show the problem So I believe it's a real bug. Further observations: a) Not reproducible with Master "LibO-dev 3.4.5 – WIN7 Home Premium (64bit) English UI [(Build ID:d337f79-a24c961-2865670-9752b71-7f8fd43 2fdd60d-fd28b6a-fd7bf20-aa369cb-28da3fb 6a9633a-931d089-ecd263f-c9b55e9-b31b807 82ff335-599f7e9-bc6a545-1926fdf)]" Slip fixed in master? So may be WFM target 3.5.0? b) Demo saved with Master after modifications due to reports looks fine in LibO 3.4.2. c) Reopening document damaged with LibO 3.4.2 in Master does not heal the problem. So seems to be a FILESAVE problem? @James: Your problem is the "#Name?" problem? Please use clear descriptions instead of "damaged"! Do you have the possibility to test that with a MASTER build? You find some "How to" information on <http://wiki.documentfoundation.org/Testing_Daily_Builds>
The problem is not #NAME? Whether or not macros run doesn't affect the issue. If you look at the area of the spreadsheet I specified, you will see the array formula {=MTDamage} under column MT, and the array formula {=DefenseNames} under "DEFENSES". Each occupies one column. After the corruption, you will see that {=DefenseNames} has disappeared, and {=MTDamage} now occupies two columns: its original, and the one formerly occupied by {=DefenseNames}
Of course, the "#Name?" only is a symptom, not the root of the problem. I did a probe with 'Front.I7' and saw 'Front.I7' 'Front.J7' ------------------------------------------------------------------------- LO data corruption.ods: {=MTDamage} {=DefenseNames} original document Saved with LibO 3.4.2RC2: {=} {=} !!! Saved with OOo 3.4: {=MTDamage} {=DefenseNames} Saved with LibO Master: {=MTDamage} {=MTDamage} !!! Saved with OOo 3.1.1: {=MTDamage} {=MTDamage} !!! Saved with LibO3.3.3 Port: {=MTDamage} {=MTDamage} !!! So the only Version really working in a correct was was OOo 3.4 In Master the problem is not solved ('Front.J7' - {=MTDamage}), the symptoms only are less visible. @James: Your sample document is very complex, do you see a possibility to contribute a more simple one what might ease debugging? Although I believe that it's a problem with all OS - what's your OS? @Kohei Please feel free to reassign if it’s not your area or if provided information is not sufficient.
@Rainer, I don't see any problems when I load this document with a fresh build from 3-4 except for some expected #Value problems. Only difference might be that I have macros disabled.
@markus: The #VALUE problem indeed appears with disabled macros. If you see {=DefenseNames} instead of {=MTDamage} in 'Front.J7' that would be a sign for a fix. I can't check that because my Master Build ids from 2077-07-11 and I doubt that I'll get a new one before August. Afaik we will get an 3.4.2RC3, what should be suitable for a test?
I can confirm that there seems to be no problem with dev-build "LibreOffice 3.4.1 RC - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:201) from libreoffice-3-4~2011-07-22_15.35.00_LibO_3.4.2rc1_Win_x86_install_multi.exe]", what ever that might mean.
I'm running Mac OSX 10.6.8. I just tried a day or two old LibO-dev 3.5.0. That still has the problem. I'd love to pare down the document to a simpler test case, but I have no idea where to begin. I don't know what's triggering the problem, so I don't know what to keep and what to leave out. @markus, did you save as well as load? Just loading won't do it. Except in rare cases I haven't been able to reproduce, LibO won't show the problem live, right after you've performed the steps I described, not even when you switch sheets. You have to save and restart.
(In reply to comment #7) > I just tried a day or two old LibO-dev 3.5.0. That still has the problem. Tried again after your comment (to be 100% sure) and saw the problem again. Seems I forgot <enter> after I modified the range during my test from Cemment 6, reopening the test doc range till ended with 113. The problem still exists for me in latest build from 3.4 branch.
I still can reproduce it but I noticed some problems in master with boost::intrusive_ptr.
(In reply to comment #9) > I still can reproduce it but I noticed some problems in master with > boost::intrusive_ptr. That ptr assert is fixed with 61674465b74f60d7ddb2d7a0fa0e17c9990f6301
Fixed in master http://cgit.freedesktop.org/libreoffice/core/commit/?id=90e489f068d09aaaf46ab15d35091198ed84bed1
This should be fixed in 3.4.4.
On 3-4 branch http://cgit.freedesktop.org/libreoffice/calc/commit/?h=libreoffice-3-4&id=6dcc0967b83b77ab289abcb1a3531469c6444a93