Apache OpenOffice (AOO) Bugzilla – Issue 3360
Main Memory Shortage on MS Word doc open
Last modified: 2002-11-29 09:45:35 UTC
A "very small" MS Word document containing two MS Equation 3.0 objects and some text crashes OO on opening. The error message "Main Memory Shortage. Please quit other applications or close some windows before continuing" appears, and OO comes down hard ("An Unrecoverable error has occurred"). This problem is evident on Windows 98 SE on an Athlon XP system and Solaris 8 on an UltraSPARC 30. The URL points to a document which will reproduce this error (20k). Removing the equations OR the text below them seems to stop the error; the equations are usually not properly displayed in either case however. Note the document opens OK in Word 97 or Word 2k.
Created attachment 1157 [details] MS Word document that replicates the crash
Reproducable if there's less than 1.1GB of memory: The original request size (decimal + hexadecimal) - rtl_allocateMemory(unsigned long 1157627904) - rtl_allocateMemory(unsigned long 0x45000000) Here's the stack trace: SAL3! osl_assertFailedLine + 246 bytes __rtl_memory_dequeue(__rtl_memory_desc_st * * 0x0012c4f4, unsigned int 1157627912) line 1002 + 28 bytes rtl_allocateMemory(unsigned long 1157627912) line 1467 + 13 bytes TL641MI! operator new(unsigned int) + 58 bytes SOT641MI! ReadClipboardFormat(class SvStream &) + 82 bytes SOT641MI! StgCompObjStream::Load(void) + 295 bytes SOT641MI! Storage::GetClassName(void) + 31 bytes SOT641MI! SotStorage::GetClassName(void) + 150 bytes SO641MI! SvStorage::GetClassName(void) + 93 bytes SO641MI! SvFactory::CreateAndLoad(class SvStorage *,unsigned char) + 100 bytes DL641MI! SvxMSDffManager::CreateSdrOLEFromStorage(class String const &,class SvStorageRef &,class SvStorageRef &,class Graphic const &,class Rectangle const &,class SvStream *,unsigned long) + 2821 bytes SW641MI! SwWW8ImplReader::ImportOleBase(class Graphic &,unsigned char,class Graphic const *,class SfxItemSet const *) + 1354 bytes SW641MI! SwWW8ImplReader::ImportOle(class Graphic const *,class SfxItemSet const *) + 94 bytes SW641MI! SwWW8ImplReader::ImportGraf(class SdrTextObj *,class SwFrmFmt *,unsigned char) + 1877 bytes SW641MI! SwWW8ImplReader::ReadChar(long,long) + 641 bytes SW641MI! SwWW8ImplReader::ReadChars(long &,long,long,long) + 77 bytes SW641MI! SwWW8ImplReader::ReadText(long,long,short) + 416 bytes SW641MI! SwWW8ImplReader::LoadDoc1(class SwPaM &,class WW8Glossary *) + 2731 bytes SW641MI! SwWW8ImplReader::LoadDoc(class SwPaM &,class WW8Glossary *) + 799 bytes
Reassigned to Michael.
Hi Caolan, just guessing but could you have a look at this, please, and then assign to the responsible developer? To me, this looks like a 'byte reversal' of the length field, but not an endianess issue (same effect on X86 [little endian] and SPARC [big endian]). Thanks, Matthias
Created attachment 1343 [details] patch to so3\source\inplace\embobj.cxx
Well its not the ww8 filters fault anyway, the finger of death points towards so3 or sot. The attached patch would fix this particular bugdoc but theres still an underlying problem of some kind. cmc->mba: Methinks this bundle of joy is for you... i.e. in so3/source/inplace/embobj.cxx SvEmbeddedObject::ConvertToOle2 has a table of recognized ole types for some sort of "flattened" ole tree which it uses to set the class id (or something of that nature) of an expanded ole tree made from the flattened version. When it doesn't find a recognized type it is setting an empty type and on reloading this tree in sot ReadClipboardFormat ends up with a bad length. The attached patch makes the Equation 3.0 type a recognized type so that the bug doesn't get triggered, but thats not really the true problem. Theres either something not working with the idea of setting an empty class type for the object on line 1502 with rDest->SetClass( SvGlobalName(), nCbFmt, aSvrName ); or sot is getting confused on loading such a type, or there's some interaction with a preexisting compobj stream in the flattened version.
I will have a look on it later.
-
*** Issue 4233 has been marked as a duplicate of this issue. ***
cmc->mba: The patch attached to issue 4233 is pretty much the true solution to this, i'll leave it up to framework to apply it and see if theres other like it to be fixed. <waffle...> The original clipboard name of the object is stored null terminated, and a count is prepended which includs this byte. The len is read, and buffer of equal len alloced and read into. This buffer up to and including the 0 terminator* is assigned to a string. At a later stage this string is written back as a clipboard name, i.e. back to a byte sequence with its len prepended. Its written to disk up to the first 0. But the String.Len() returns the size of the buffer, which is the len of the string plus 1 for the redundant extra 0. One is added to this value and prepended to the string. So the final string len is prepended 1 too large. The problem doesn't arise if the name is a recognized one because then the string constructor without len argument is used. There are likely to be more issues like this in our codebase, perhaps we should consider modifying the String class to warn when a 0 value is stored as the last char (or any char) </waffle>
Created attachment 1661 [details] new[] --> delete[]
Working now in SRX643m
Will work with OpenOffice 643 release.
*** Issue 7775 has been marked as a duplicate of this issue. ***
Should work well in OpenOffice 643C