Apache OpenOffice (AOO) Bugzilla – Issue 73969
WW8: file size of .doc increases almost 1000x when importing VBA code
Last modified: 2013-08-07 15:31:14 UTC
When I open the attached DOT Word template OpenOffice blows up the size of the file to several 100MB before opening it. Note that I'm opening as template, so a new Untitled1 document is created. There is absolutely no reason why OpenOffice should perform any write access at all on the file when opening as template, let alone something weird such as increasing the filesize 1000-fold. The problem has been confirmed by other users on different computers with OOo 2.1 and 2.04 under Linux and Windows. Interestingly the file always grows to exactly the same size of 744950784 Bytes, so the problem is completely deterministic.
Created attachment 42552 [details] WARNING! File grows to 711MB when opened by OOo
The bug only triggers if Tools/Options/Load/Save/Load Basic code to edit is checked. Another user has reported that the bug does not occur under OOo 2.0.3. If that is accurate, it was introduced in 2.0.4.
The file size of the attached document will increase to 710 MB when importing (!) into OOo. This does not happen when the option "Load Basic code to edit" is enabled. I also confirm, that his worked fine last in OO 2.0.3.
@mru: You mean This does not happen when the option "Load Basic code to edit" is DISABLED.
ab->mav: As discussed, please have a look
The resizing happens because the implementation of the method "ContainerRecReader::Read()" provides a wrong offset for the SeekRel operation. This is an old feature that seeking to an offset after the EOF resizes streams based on SvStream interface. But the stream readonly, so it should be impossible to resize it. The SotStorage is fixed now for the issue 75574 so that such seek operation on a readonly stream does not lead to the stream resizing. But I suspect that the mentioned above "Read()" method must be fixed as well, since it provides the offset "0x2C000000". Looks pretty like the offset was wrongly read from the stream ( Big Indian - Little Indian, or a wrong size of the read data ). The reading happens in msocximax.cxx:699. MAV->DR: Please take a look. I have introduced a new assertion in cws "fwk64" for the case when readonly stream is resized by seek operation, because usually that means that the offset is wrong. The text of the assertion is "Trying to resize readonly stream by seeking! Could be a wrong offset!". This assertion was triggered three times during loading of the attached document. I will attach the stacks including the stack for the original problem.
Created attachment 43830 [details] Three stacks pointing to tries to resize readonly streams by seeking. The third stack is related to the huge resize of the file.
started
Problem with increasing file size has been resolved, have to look somewhat deeper into the import of the form controls -> OOo 2.x
is that correct that the fix for growing file size will be implemented on 2.3, but some other issue will be for 2.3 ? if yes, it maybe better to create another issue ? Thanks
target 3.0
Daniel, I think that this issue might need some attention. Or should we change the target?