Issue 127568 - Diagrams become corrupt (not retrievable) when Calc document is saved
Summary: Diagrams become corrupt (not retrievable) when Calc document is saved
Status: CLOSED FIXED
Alias: None
Product: Calc
Classification: Application
Component: save-export (show other issues)
Version: 4.1.4
Hardware: Mac macOS 10.13
: P5 (lowest) Blocker (vote)
Target Milestone: 4.1.5
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords: needhelp
Depends on: 127580
Blocks:
  Show dependency tree
 
Reported: 2017-10-22 11:50 UTC by aauv
Modified: 2022-10-28 12:54 UTC (History)
9 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: 4.1.4
Developer Difficulty: ---
jim: 4.1.5_release_blocker+


Attachments
Calc document with corrupt diagram (10.96 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-10-22 11:50 UTC, aauv
no flags Details
Mac file created as described (12.20 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-10-27 08:06 UTC, aauv
no flags Details
Win file created as described (13.12 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-10-27 08:08 UTC, aauv
no flags Details
Mike's document with corrupt chart (19.32 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-10-27 22:42 UTC, Dave Fisher
no flags Details
Mike's screen shots (113.10 KB, application/vnd.oasis.opendocument.text)
2017-10-27 22:42 UTC, Dave Fisher
no flags Details
Diff of 4.1.3 and 4.1.4 (30.73 KB, patch)
2017-10-28 16:56 UTC, Dave Fisher
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description aauv 2017-10-22 11:50:41 UTC
Created attachment 86232 [details]
Calc document with corrupt diagram

This wasn't an issue of AOO 4.1.3, but is an issue of AOO 4.1.4:

When a digram is created within a Calc table, and the document is saved, the diagram is corrupt after re-opening the document.

The diagram has withered to a white rectangle; when this is double-clicked, the diagram data has vanished.

This has been tested on three different machines

Mac mini, macOS 10.10.5
iMac, macOS 10.13
MacBook Air, macOS 10.13
Comment 1 oooforum (fr) 2017-10-22 16:51:57 UTC
I was not able to reproduce with AOO 4.1.4 and Win7 x64 Pro
Comment 2 aauv 2017-10-22 20:55:42 UTC
I checked myself on a virtual Win 7 machine (VirtualBox) and can confirm that, there, I neither can reproduce the bug.

Hence it may be a problem of the macOS implementation of AOO.
Comment 3 Larry Gusaas 2017-10-24 11:38:48 UTC
Created a copy of aauv's file. Inserted my own diagram using his data. Saved and then reopened document. Diagram disappeard.

Same behaviour as aauv.

MacBook Pro
macOS 10.13 High Sierra
Apache OpenOffice 4.1.4 (AOO414m5(Build:9788)  -  Rev. 1811857)
Comment 4 Patricia Shanahan 2017-10-24 13:03:18 UTC
One possibility is that the Mac is failing to display the "Update all Links" dialog on opening the file, and is taking the default "No" answer. The dialog was added for spreadsheets as part of the changes for 4.1.4.
Comment 5 Jim Jagielski 2017-10-24 14:21:54 UTC
I can confirm that with the provided doc, the diagram shows up as corrupted on macOS 10.12.

Not seeing anything between 4.1.3 and 4.1.4 mac specific that would cause this problem, but will dig in
Comment 6 Patricia Shanahan 2017-10-24 14:40:22 UTC
(In reply to Jim Jagielski from comment #5)
> I can confirm that with the provided doc, the diagram shows up as corrupted
> on macOS 10.12.
> 
> Not seeing anything between 4.1.3 and 4.1.4 mac specific that would cause
> this problem, but will dig in

Can you find out whether line 288 in main\sfx2\source\appl\linkmgr2.cxx is being reached during the failing file open?

That is a key test for my current hypothesis. If it is not being reached, the hypothesis is false. If it is being reached, the hypothesis is likely to be correct.
Comment 7 Jim Jagielski 2017-10-26 12:01:24 UTC
I set breakpoints on both:

   (lldb) breakpoint set --file main/sfx2/source/appl/linkmgr2.cxx --line 288
   (lldb) breakpoint set -n LinkManager::GetUserAllowsLinkUpdate
Breakpoint 4: where = libsfx.dylib`sfx2::LinkManager::GetUserAllowsLinkUpdate(Window*), address = 0x000000010070a260

and when opening up the corrupted file, neither breakpoint
was reached. :/
Comment 8 Jim Jagielski 2017-10-26 20:40:44 UTC
OK... I had assumed that I could simply open the provided calc document to see if the rebuild of macOS works. From further reading this does not look like the case, since the doc does not open correctly using anything.

My question is should the diagram NOT be corrupted upon opening up the provided file?
Comment 9 Larry Gusaas 2017-10-26 22:03:19 UTC
(In reply to Jim Jagielski from comment #8)
> OK... I had assumed that I could simply open the provided calc document to
> see if the rebuild of macOS works. From further reading this does not look
> like the case, since the doc does not open correctly using anything.
> 
> My question is should the diagram NOT be corrupted upon opening up the
> provided file?

The file is corrupted upon saving. When I tested making a new document and saving it the diagram was gone when I opened it again.

I used his document, deleted the empty image window, highlited the data in columns A&B, did Insert/Chart to create a bar chart, saved and closed.
Chart gone when I reopened.
Comment 10 Patricia Shanahan 2017-10-27 01:38:43 UTC
Opening the supplied document on a Window 8.1 machine results in the blank chart. Creating and saving a similar document results in a non-corrupt chart that displays as expected on load.

I have a couple of ideas for experiments, but no Mac to run them on.

1. Find the first revision that fails. I understand that it worked in 4.1.3, so somewhere between 4.1.3 and 4.1.4 there was a change that switched it from working to not working. What was that change?

2. Produce two files, one on a Mac and the other on a non-Mac, following exactly the same procedure. The resulting files should be close to identical. Given such a pair, I could work on finding what is different between them.
Comment 11 aauv 2017-10-27 08:06:27 UTC
Created attachment 86237 [details]
Mac file created as described
Comment 12 aauv 2017-10-27 08:08:05 UTC
Created attachment 86238 [details]
Win file created as described
Comment 13 aauv 2017-10-27 08:10:03 UTC
I have submitted two files created by the same procedure:

* Start AOO
* Create new table document (by clicking in the start center)
* Enter data in A1:B4 as provided
* Select A1:B4
* Command "Insert : diagram..."
* Button "Finish"
* Deactivate diagram by click into A10
* Shift diagram aside in order to make A1:B4 visible
* Command "File : Save"
* Use dialog to save the file on the desktop
* Quit AOO.
Comment 14 Patricia Shanahan 2017-10-27 12:32:07 UTC
I have started analysis of the differences between the two files discussed in Comment 13. I unzipped both files, and started comparing them.

Each has a subdirectory "Object 1" that I would expect to describe the diagram. All three files in the mac version are empty:

$ ls -l {win,mac}/'Object 1'
mac/Object 1:
total 0
-rw-r--r--+ 1 Patricia Patricia 0 Oct 27  2017 content.xml
-rw-r--r--+ 1 Patricia Patricia 0 Oct 27  2017 meta.xml
-rw-r--r--+ 1 Patricia Patricia 0 Oct 27  2017 styles.xml

win/Object 1:
total 13
-rw-r--r--+ 1 Patricia Patricia 6858 Oct 27  2017 content.xml
-rw-r--r--+ 1 Patricia Patricia  584 Oct 27  2017 meta.xml
-rw-r--r--+ 1 Patricia Patricia 1395 Oct 27  2017 styles.xml

This seems to be a highly significant and relevant difference.
Comment 15 Patricia Shanahan 2017-10-27 18:49:14 UTC
I have done two tests based on the pair of files from Comment 13. I unzipped them both, switched the files in the 'Object 1' subdirectory, and zipped them again creating two new files, AlmostMac.ods and AlmostWin.ods.

AlmostMac.ods, which is like Mac.ods except for having the win version of the 'Object 1' files, displays the chart correctly on 4.1.3, Windows 8.1. On the other hand, AlmostWin.ods, which is like Win.ods except for having zero length 'Object 1' files, fails the same way as Mac.ods.

My conclusion is that the zero length files in 'Object 1' in Mac.ods are both necessary and sufficient to reproduce the bug. Debug needs to focus on why those files are empty when saved by 4.1.4 on a Mac.
Comment 16 Dave Fisher 2017-10-27 22:42:14 UTC
Created attachment 86239 [details]
Mike's document with corrupt chart
Comment 17 Dave Fisher 2017-10-27 22:42:59 UTC
Created attachment 86240 [details]
Mike's screen shots
Comment 18 Dave Fisher 2017-10-27 22:44:05 UTC
From the users ML:
Thanks Dave for responding so promptly.

Attached is a typical spreadsheet, but fewer columns and rows than most of the others.  It records weight in kilograms for different stages of chemotherapy treatment by ingested tablets.  Maintaining stable weight is one useful indicator of drug side-effects.  The data is personal but not private - indeed, the intention is to publish it later so feel free to share it with others if that is useful.  This is the sequence of events:

1.  open spreadsheet, select all of the data (in the attached, A1 - D126)
2.  select Insert Chart
3.  select Line then Lines only
4.  select Finish.   The chart displays in the area ("A") bounded E12 - K33
5.  select Save.  The chart is still displayed
6.  select Close

7.  open the spreadsheet.  The data is correct, but there is no chart, as pre 4.1.4 there would have been.  There is an area "B" bounded by J17 - K21 ( or an area of equivalent size located nearby) indicated by the row-column grid being overwritten.  If that area is selected then the boundaries of area A show up marked with the 8 small green squares.  But the area shows the row-column grid but no chart.  The area A can be moved, and area B moves with it.  It is possible to insert the charts several times, each saved as the blank areas A and B.  Blank areas A and B can be deleted.  Because area A can be moved the above locations might be the same size but located elsewhere on the sheet.

Another oddity which I've just noticed when preparing the attached screen dumps (using OSX's Shift-Command-4).  The double sets of green area markers don't show on ther spreadsheet but do show when the screen dump is inserted into the text document, using the Insert- Picture- From file commands.  If you click inside the double-marked image then the outermost of the doubled marks disappears.  I think I've got those details correct, it's tricky making them happen and keeping track!  Well, tricky for me.

I trust the above means you can reproduce the problem.  Good luck with resolving it.

cheers,

Mike
Comment 19 Dave Fisher 2017-10-28 16:56:21 UTC
Created attachment 86242 [details]
Diff of 4.1.3 and 4.1.4

I hope that the attached diff is helpful in finding where the issue exists.
Comment 20 Patricia Shanahan 2017-10-28 17:13:14 UTC
(In reply to Dave Fisher from comment #16)
> Created attachment 86239 [details]
> Mike's document with corrupt chart

This file has zero length for each of the three 'Object 1' directory files.
Comment 21 Patricia Shanahan 2017-10-28 17:14:45 UTC
(In reply to aauv from comment #0)
> Created attachment 86232 [details]
> Calc document with corrupt diagram
> 
> This wasn't an issue of AOO 4.1.3, but is an issue of AOO 4.1.4:
> 
> When a digram is created within a Calc table, and the document is saved, the
> diagram is corrupt after re-opening the document.
> 
> The diagram has withered to a white rectangle; when this is double-clicked,
> the diagram data has vanished.
> 
> This has been tested on three different machines
> 
> Mac mini, macOS 10.10.5
> iMac, macOS 10.13
> MacBook Air, macOS 10.13

This file has length zero for each of the three 'Object 1' files.
Comment 22 tintin60 2017-11-02 13:27:03 UTC
Hi,

I just received a new version : https://dist.apache.org/repos/dist/dev/openoffice/macOS-4.1.4-20171101/binaries/fr/Apache_OpenOffice_4.1.4_MacOS_x86-64_install_fr.dmg

I tried it and it operates properly. Diagrams remain at the next opening after being saved.
Comment 23 Larry Gusaas 2017-11-03 00:53:02 UTC
(In reply to tintin60 from comment #22)
> Hi,
> 
> I just received a new version :
> https://dist.apache.org/repos/dist/dev/openoffice/macOS-4.1.4-20171101/
> binaries/fr/Apache_OpenOffice_4.1.4_MacOS_x86-64_install_fr.dmg
> 
> I tried it and it operates properly. Diagrams remain at the next opening
> after being saved.

I tried it and spreadsheets work correctly.

However, the new version breaks Base. A current database no is no longer fully functional. I will give details and a sample database later tonight.
Comment 24 oooforum (fr) 2017-11-03 07:30:03 UTC
(In reply to Larry Gusaas from comment #23)
> However, the new version breaks Base. A current database no is no longer
> fully functional. I will give details and a sample database later tonight.
This issue talks about Calc.
Thanks to open a dedicated issue for Base.
Comment 25 Larry Gusaas 2017-11-03 07:35:54 UTC
(In reply to oooforum (fr) from comment #24)
> (In reply to Larry Gusaas from comment #23)
> > However, the new version breaks Base. A current database no is no longer
> > fully functional. I will give details and a sample database later tonight.
> This issue talks about Calc.
> Thanks to open a dedicated issue for Base.

I will as soon as I have time. I posted here because the fix for the problem in Calc created a new problem in Base. This version is still not fit for release.
Comment 26 Larry Gusaas 2017-11-03 11:47:30 UTC
(In reply to Larry Gusaas from comment #25)
> (In reply to oooforum (fr) from comment #24)
> > (In reply to Larry Gusaas from comment #23)
> > > However, the new version breaks Base. A current database no is no longer
> > > fully functional. I will give details and a sample database later tonight.
> > This issue talks about Calc.
> > Thanks to open a dedicated issue for Base.
> 
> I will as soon as I have time. I posted here because the fix for the problem
> in Calc created a new problem in Base. This version is still not fit for
> release.

Created an issue in Bugzilla https://bz.apache.org/ooo/show_bug.cgi?id=127580
Issue 127580 - Fix for Issue 127568 created a new bug in Base
Comment 27 Jim Jagielski 2017-12-09 20:19:39 UTC
Fixed in 4.1.5-dev as of r1817525 (at latest).

Will keep open to check RCs