Bug 39485 - Data corruption for matrices
Summary: Data corruption for matrices
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected)
3.4.1 release
Hardware: Other All
: medium critical
Assignee: Eike Rathke
Whiteboard: target:3.4.4
Keywords: regression
Depends on:
Reported: 2011-07-22 18:08 UTC by James
Modified: 2011-12-23 17:13 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

sample file to demonstrate data corruption (33.11 KB, application/vnd.oasis.opendocument.spreadsheet)
2011-07-22 18:08 UTC, James

Note You need to log in before you can comment on or make changes to this bug.
Description James 2011-07-22 18:08:55 UTC
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.
Comment 1 Rainer Bielefeld Retired 2011-07-23 00:36:27 UTC
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?

- 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
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?

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>
Comment 2 James 2011-07-23 10:43:09 UTC
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}
Comment 3 Rainer Bielefeld Retired 2011-07-24 02:34:19 UTC
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.

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?

Please feel free to reassign if it’s not your area or if provided information is not sufficient.
Comment 4 Markus Mohrhard 2011-07-24 11:57:00 UTC

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.
Comment 5 Rainer Bielefeld Retired 2011-07-24 21:56:36 UTC
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?
Comment 6 Rainer Bielefeld Retired 2011-07-25 00:15:11 UTC
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.
Comment 7 James 2011-07-25 03:10:59 UTC
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.
Comment 8 Rainer Bielefeld Retired 2011-07-25 03:39:54 UTC
(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.
Comment 9 Markus Mohrhard 2011-07-25 04:36:52 UTC
I still can reproduce it but I noticed some problems in master with boost::intrusive_ptr.
Comment 10 Eike Rathke 2011-08-24 19:16:34 UTC
(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
Comment 12 Kohei Yoshida 2011-09-13 11:05:25 UTC
This should be fixed in 3.4.4.