Issue 123539 - CRASH when open particular .XLS with 3D Chart
Summary: CRASH when open particular .XLS with 3D Chart
Alias: None
Product: Calc
Classification: Application
Component: open-import (show other issues)
Version: 3.4.0
Hardware: All Windows 7
: P3 Major (vote)
Target Milestone: 4.1.0
Assignee: Armin Le Grand
QA Contact:
Keywords: crash, needmoreinfo
Depends on:
Reported: 2013-10-24 06:56 UTC by liuping
Modified: 2017-05-20 10:35 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

sample file (550.00 KB, application/
2013-10-24 06:56 UTC, liuping
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description liuping 2013-10-24 06:56:38 UTC
Created attachment 81810 [details]
sample file

Build Info:
AOO401m5(Build:9714)  -  Rev. 1524958

1. Open the sample file
2. Check 3D Surface chart in file

Can't load the sheet.
Comment 1 Rainer Bielefeld 2013-10-25 09:09:29 UTC
Reproducible with reeporter's  "AOO 4.0.1   – German UI / German locale  [Rev. 1524958 2013-09-20 11:40:29]" on  German WIN7 Home Premium (64bit)", “historic”  4.0  User Profile used for all  predecessor versions.

Additional Info
(a) Any WIN AOO / LibO OOo (3.0 and later) version I try stops responding with 
    maximum processor load. 
(b) OOo 2.0.3 opens document after long time without 
    showing chart, same with Calligra Sheets.
(c) Softmaker FreeOffice opens the document without any problems, also 
    MS EXCEL Viewer
(d) Still Reproducible with "AOO 4.0.1   – German UI / German locale  
   [Rev. 1524958 2013-09-20 11:40:29]" on  German WIN7 Home Premium (64bit)",
   “historic”  4.0  User Profile used for all  predecessor versions

(e) are yuo sure that the chart causes the problem?
(f) Please always contribute information with what OS with what localization 
    you did your tests!
Comment 2 Armin Le Grand 2014-02-17 23:47:22 UTC
Checked import, and it is indeed the chart creating 3D objects using the UNO API. Checked that chart in excel viewer and it is made up of a massive count of surfaces. When the chart tries to create all of these, a huge amount of recursion occurs, mainly because the UNO API implementation has to do many resets in the 3D stuff; e.g. when one surface gets inserted/changed, the outmost scene will get invalidates and all 2D BoundRects derived from the 3D BoundRects will be reset. This is due to the fact that AOO has to map the scene content to a single window and thus has to react on each geometry change that may change the default calculated transformation to the 2D canvas of the whole 3D scene. And there are other places where the UNO API correctly has to do such internal resets...
Already tried to remove some of these for test purposes, but the shear amount of 3D objects and the usage over the UNO API to be created makes it nearly impossible to improve this, e.g. the UNO API uses the 2D internal GetBoundRect for single 3D objects when their Size is to be set as 2D (no idea why the chart does that, but it happens). That 2D BoundRect depends on the completely calculated 3D scene transform and thus on all other existing objects in that 3D scene which (as explained above) get reset every time a member gets changed in a way that indeed can influence that transformation.
Maybe a mode similar to ModelLock should be added to encapsulate 3D scene creations from the chart over the UNO API, but I am not sure how far this can be safely done...
Comment 3 Armin Le Grand 2014-02-17 23:51:23 UTC
Checked again with MS, we talk about a data range of '=data!$A$1:$CW$101', thus potentially 100x100 (10.000) 3D surfaces to create over the UNO API, There are 100 single data ranges defined which use these...
Comment 4 Armin Le Grand 2014-02-18 01:12:26 UTC
Disabled even more stuff for 3D when the model is locked. There are 100 * 100 * 5 * 3 = 150.000 3d shapes involved, and these get created multiple times (xls import to chart model, creation, export of chart model, creation, re-import of chart model, creation). It also has multiple groups of 150.000 objects, so its even more.
The 3D chart I get after 130s loading with my quick hacks looks nice and is rendered in 17s using the 3D prmitives using the current 3D software renderer.
This shows that the charts object creation using UNO API needs massive rework - it is not designed/implemented currently for such data masses as in this example. My local quick changes will have effects on other 3D areas, it was just a rough test.
Comment 5 Armin Le Grand 2014-02-18 17:52:54 UTC
Doing a more conservative approachand checking for not too dangerous changes to speedup the UNO API object creation. Also will need to buffer the primitive data that ViewContactOfSdrOle2Obj fetches from the chart (using the ChartHelper::tryToGetChartContentAsPrimitive2DSequence tunnel) since this is done each time the range is needed currently, also securing this again with recognizing the chart changes (both not needed wit aw080, btw)...
Comment 6 Armin Le Grand 2014-02-18 20:21:38 UTC
Checked a more simple 3D chart if it still reacts on all events/changes, looks good. Re-checking changes and do some investigations if these may break something else...
Comment 7 SVN Robot 2014-02-18 21:18:14 UTC
"alg" committed SVN revision 1569529 into trunk:
i123539 some optimizations for 3D chart geometry creation using UNO API
Comment 8 Armin Le Grand 2014-02-18 21:18:18 UTC
Looks good, decided to checkin.
Comment 9 Armin Le Grand 2014-02-18 21:19:18 UTC
Okay, working at all and much faster now. Faster for all types of 3D charts, imported from external format or loading own format.
Comment 10 Armin Le Grand 2014-02-19 15:16:25 UTC
Checked with new build trunk version (still debug version, non-pro, but no concrete debug yet), load to reday chart takes 67s. Will be interesting to see the pro version.
Comment 11 Armin Le Grand 2014-02-19 15:27:27 UTC
Buildbot version needs 37s
Comment 12 Kay 2014-02-25 00:16:12 UTC
Build info:
AOO410m1(Build:9750)  -  Rev. 1566593

Linux 32

Won't open file at all and locks up AOO 4.1.0. Request to change to "unresolved".
Comment 13 liuping 2014-02-25 06:01:32 UTC
AOO410m1(Build:9750)  -  Rev. 1570848
Rev.1570848 on windows7 ,Pass
Comment 14 Armin Le Grand 2014-02-25 20:31:22 UTC
@Kay: r1566593 is not new enough, the fix went into r1569529 as comment 7 shows.
Comment 15 Oliver-Rainer Wittmann 2014-04-02 11:30:33 UTC
Verified on Ubuntu 10.04 (64bit) with build from branch AOO410 (rev. 1583666)

Verified on Windows 7 with local build of branch AOO410, rev. 1582710 and with buildbot build, rev. 1582709
Comment 16 Kay 2014-04-02 23:30:40 UTC
OK, now using our RC candidate --

AOO410m15(Build:9761)  -  Rev. 1583666
2014-04-01 15:58 - Linux i686

KDE 4.10.

I WAS able to open this, but when I did anything to it -- clicked on it, etc. there was no response and it hung up my GUI session -- which I exited.

At this point, I don't know what the expectations should be regarding processor/memory for a better experience by the end user.

Just some questions.

Thanks for all the hard work.
Comment 17 Armin Le Grand 2014-04-04 09:58:06 UTC
Hi Kay,

thanks for the feedback, much appreciated. On Win7 I have good response times once it is rendered; it *should* be good on linux too, both use the internal software 3D renderer and the same (system-independent) primitive representation. I will take a 2nd look on a linuy system...
Comment 18 Armin Le Grand 2014-04-04 10:13:52 UTC
Tried with the 410 beta on a fresh Fedora64. I get a short 'not responding' message when loading, but not quitting returns to AOO and I can quickly scroll and zoom in the loaded chart. I would guess that the calculation time - even when greatly reduced - is long enough to make the linux ask that question due to AOO not reacting during that time (old singletasking, argh), but all works well and quick.