OS: Windows 7 Home Premium 64 bits SP1 (French) Java: SE 7 U5 or SE 6 U33 System RAM: 16 GB LibreOffice 3.5.5 Extensions: French, Spanish, Italian and English dictionaries; PDF import; presentation minimizer. Bug occurs with a large odt file (350 pages, 99 images, 232 MB). Once the file is loaded, the RAM used by "soffice.bin" is some 130-160 MB. When saving the file the first time, it appears that "soffice.bin", as seen in task manager, increases considerably the RAM it uses, up to 800-900 MB (particularly at the end of the saving process, when the screen is freezed). When the file is saved and the access to document is released again, "soffice.bin" does not go back to its former RAM use, but uses some 250 MB (even when not doing anything). After each time the file is saved, the RAM used by "soffice.bin" is higher and higher, up to 450 MB when not doing anything. From this state, at the next saving of the file, the RAM used climbs up to 1.2 GB, and, once this amount is reached, Writer / LibreOffice crashes. Three to four successive saves of the file (including automatic saves) are enough to go to the crash. This resembles to a memory leak in "soffice.bin".
Bug is seen with LibreOffice 3.5.5; it did not exist with 3.4.6 version, on the same computer with the same file.
What file format do you use for saving your document? odt or doc? Without a file to make tests it not possible to confirm your bug report. Best regards. JBF
Hello, The format I use for saving my file is odt. I cannot send you the file I use: it is a "private" file, a book that I am writing. Its characteristics: 800000 characters, 350 pages, 100 high definition images, 230 MB. I could try to make a "ipsum dolorem" file with such characteristics, but how to send it to you?? I can also take screen copies of task manager showing the "memory leak" of "soffice.bin". I have made tests without Java being activated, with Java 6.33, with Java 7.05 and the result is the same: bug does not seem related to Java. I can also do some tests with LibreOffice 3.5.4 under Ubuntu 12.04 LTS (on the same computer) with the same file, and tell you if LB also crashes. Best regards, Michel Nallino
I have made some tests with LB 3.5.4 under UBUNTU 12.04 LTS (64 bits). It appears that the same memory leak exists: I open the file, change a character, save the file then do it again. At the sixth time, the amount of RAM used by "soffice.bin" (after having successfully saved the file) is 1.2 GB (!). And during the file saving it reached 1.5 GB (as reported by system monitor). The amount "at rest" has increased of some 200 MB after each file save. This shows that "soffice.bin" doesn't release the memory it uses. However, there are two differences with LB 3.5.5 under Windows 7 SP1 (64 bits): under Ubuntu, the % of CPU used by "soffice.bin" climbs up to 96%, while it does not go over ~20% under Windows (same computer, I7 quadricore processor in each case). And, under Ubuntu, there is no crash (there will be maybe, just before to reach 16 GB, the computer memory!). Another test: from within LB, once the file is open, select all, copy and paste in a new file; this works under Windows, but after this the RAM used by "soffice.bin" is 800 MB. Same test under Ubuntu, same result. The bug really seems to be a memory leak: "soffice.bin" doesn't release all the RAM. Just do this several times (for example with automatic save), and the amount of RAM used by "soffice.bin" increases regularly up to crash. As I told, I have never noticed a crash with this same file and LB 3.4.6. Best regards, Michel Nallino
I have found a temporary workaround working with Windows: download "sysinternals utilities" suite from Microsoft download site. Use "RAMMap.exe" jointly with LB (keep RAMMap running). After each file save, in RAMMap "Empty" menu, click on "Empty Working Sets". This forces LB to release its memory ("soffice.bin" used RAM goes down to 20 MB after an "Empty Working Sets"). Best Regards, Michel Nallino
Probably same problem as in bug 52433. Best regards. JBF
Yes, it seems similar: memory is not released by LB, just two methods to release memory, close LB or use a tool (like RAMMap) that forces private RAM to be released. I have in my file some pictures which have been copied / pasted, but most have been put in the document by using insert / image menu. I did another test under windows: crash of LB when attempting to export file to docx; the crash occurred even before docx file could be generated. I switched to LB 3.5.5 from 3.4.6; before that I used some 3.4.x versions and 3.3.x ones under Windows. Never seen the bug with the 3.4.x or 3.3.x versions. I have seen the bug on 3.5.4 (Ubuntu) and 3.5.5 (Windows) versions. It seems typical of 3.5.x versions (and above?) Best regards, Michel Nallino
As JB said on comment6, it must be a dup. If disagree, feel free to update the status of this bug. *** This bug has been marked as a duplicate of bug 52433 ***