Apache OpenOffice (AOO) Bugzilla – Issue 123870
CRASH when open Particular.xls with chart
Last modified: 2017-05-20 10:35:34 UTC
Created attachment 82124 [details] xls file with one very simple chart I created an xls file with charts in using oo. All seemed ok, but after some edits I could no longer open the file - it now crashes oo. The original file has been modified to remove almost everything - all that remains is a single chart plotting one pair of points. This works ok using Excel, and was modified using Excel on another PC. If the chart is removed and recreated, the file can be opened ok again. I am running Windows 8.1 on a Samsung laptop with i5-3210M processor. The problem was seen on oo v4.0.0, then I updated to 4.0.1 and it's still seen.
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 Modify Version due to report
(a) Already reproducible with Pre-3.4.0 (OOo 3.3.0), but because of crippled Version selector (Bug 123063) no useful info can be contributed (b) Still Reproducible with server installation of "AOO 4.1.0-Dev – English UI / English locale - [AOO410m1(Build:9750) - Rev. 1546757 - 2013-12-02]" on German WIN7 Home Premium (64bit)", own separate user profile. (c) No crash with OOo 3.1.1, but no Data range selected with that version (d) no Crash with OOo 2.0.2, Data Range "$Error.$A$2:$B$2" with that version (e) SoftMaker FreeOffice shows empty chart (f) MS Excel Viewer opens document without problems, shows vertical line with length=10 at X=0
(g) LibO 4.1 does not crash, Chart looks like in MS EXCEL Viewer
Created attachment 82126 [details] Test Kit Attached Test Kit contains 3 Documents (h) Mytest_NoGood_LibO4132.ods Has been createded from reporter's sample document using LibO 3.1.4.2 (i) Mytest_NoGood_LibO4132.xls Has been createded from Mytest_NoGood_LibO4132.ods sample document using LibO 3.1.4.2 AOO 4.1 will crash opening that document (k) Mytest_NoGood_LibO4132OOO410.xls Has been createded from Mytest_NoGood_LibO4132.ods sample document using AOO 4.1 AOO 4.1 will NOT crash opening that document (l) May be differences between both .xls help to find the vulnerability in AOO (m) Both .xls look fine in MS EXCEL Viewer
Taking a look. In StartEndListening::operator() a ScRange is created which has a nCol (column) set to -27541. This is later used as index to an array which crashes. Resetting it to null makes the load work (it's actually not the load but a XclImpChart::Convert which also sets the listeners to the corresponding chart cells). Thus, ScRefTokenHelper::getRangeFromToken makes something wrong. Checking...
The ScSingleRefData the data is copied from is already wrong. Lets see where this is created...
ScSingleRefData has no constructor, so its not easy to see where it gets constructed. This also means that the members are not initialized (which may already be the problem). Who is writing classes like this..?
In ScSingleRefData the flags for relative col/row are set in the dangerous case, thus the absolute values nCol/nRow should not even be used, but they get used. There is also ScSingleRefData::CalcAbsIfRel which probably should be used on the instance before usage, it needs a const ScAddress&. This i snot available at the place where it goers wrong, so this should probably be appied before and relative to something that makes sense...
Tried different solutions: - Added correctors to ScRefTokenHelper::getRangeFromToken to do CalcAbsIfRel if needed. Works, but I do not want to change that data. It hets called in running office, too, with relative entries but the absolute get used. Thus, adding an assertion there. - Added initializers for the members of ScSingleRefData and ScComplexRefData in ExcelToSc8::ConvertExternName and ExcelToSc8::Convert. Also works, but shows that a initializing constructor would work sell, too. - Added constructor to ScSingleRefData (will also work for ScComplexRefData whcih has two ScSingleRefData as members), this is probably the best thing to do. Checking that solution...
Constructor did not work, it is used in various union constructs and does not simply allow a user-defined one; added a method InitMembers instead and use that at the according places. Also exchanged the assertion in getRangeFromToken to not check for relative flags (happens too often to really be wrong), but for validity of ranges of absolute values. Checking this solution...
This works well and produces the correct result (cheched with MS stuff). Preparing commit...
"alg" committed SVN revision 1559272 into trunk: i123870 corrected import values on xml import with chart, avoid uninitialized...
Okay, done.
fixed on AOO410m1(build:9750) - rev:1566593
Change status per Shao Zhi Zhao's comment 14