Issue 67208 - linked images permanently consumes memory (regression)
Summary: linked images permanently consumes memory (regression)
Status: CONFIRMED
Alias: None
Product: Writer
Classification: Application
Component: open-import (show other issues)
Version: OOo 2.0.3
Hardware: PC Linux, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-07-10 22:39 UTC by alex69
Modified: 2017-05-20 11:17 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description alex69 2006-07-10 22:39:08 UTC
Dear All,

<summary> 
I already reported #59688 that in a writer document on opening for *all* linked
images inside memory is allocated. In case you use writer for e.g. provide some
nice text around your (linked) digikam jpegs, it can result in a hog of a huge
amount of memory (up to 800 MB for me).
  
Including OOo 2.0.2 you could work around and set free most memory if you go
through all pages in file -> page preview. Page by page you see reduction in
e.g. a task monitor.

In the current Linux rpm-release of 2.0.3 I noticed a regression: page preview
workaround does not anymore set free memory, nor it is freed by closing the
document itself. Of course closing OOo frees as last resort.

The windows version of 2.0.3 does not suffer this new issue, so I suspect the
Linux rpm's to be in some way defect. 

<own test environments and results>
Verified under Suse 9.3 and 10.1 using OOo rpm's, english and german version -->
showed above behaviour
Tested W2K SP4, german version --> worked as in 2.0.2
Tested Novell's 2.0.3 rpm's for 10.1
(ftp.suse.com/pub/projects/OpenOffice.org/10.1-i386/*) --> worked too, but may
be of older RC-basis, as Novell does often "patch" it's own sources

<Test case / description of reproduction>
- use example file from enhancement req. #59688 or generate a new writer file
and add ~30 different high resoltion (e.g. digikam) jpegs (1600x1200 or more)
and save it.
- open a task monitor to follow memory usage
- restart OOo 2.0.3 and open above sample file
- notice increasing amount of memory on opening as all images are loaded (all
OOo versions 2.x.x)
- Try to set free memory by file -> page preview and browsing through all pages.
2.0.3 will only decrease minimaly ~10%, <=2.0.2 decrease up to 95%
- Try to close document, but not OOo itself. 2.0.3 -> keeps used memory; <=
2.0.2 sets free all remaining used memory by document

<own evaluation on effect>
For my case ("Photoalbum" using ~800 MB on 1 GB main mem) using OOo 2.0.3 Linux
version slows noticably down my machine because of swapping. Maybe this new
"behaviour" has any more side effects.

Cheers, alex69
-
Comment 1 alex69 2006-07-10 22:47:03 UTC
Sorry, was not precise in reproducing description, first step should read (see
*...*):
- use example file from enhancement req. #59688 or generate a new writer file
and add ~30 different *linked* high resoltion (e.g. digikam) jpegs (1600x1200 or
more) *by using insert -> graphics -> by file and check "linked" in Popup (note:
menu items translated by myself from german version, may be named different in
english version)* and save it.
Comment 2 michael.ruess 2006-07-17 12:38:42 UTC
Reassigned to HI.
Comment 3 h.ilter 2006-07-17 16:29:33 UTC
HI->FME: Open the "System Monitor" at linux to view the system resources and use
the attachment from i59688.
From my point of view, there is a sporadic behavior in case of the memory usage,
when you close and reopen the doc again. 
Comment 4 alex69 2006-11-01 13:31:18 UTC
Just to let you know - 2.0.4 is out and still the same (I expected that as no
change in this issue happened since). imposeSo I just want again to point out
straightforward:

* This issue was introduced by 2.0.3 Linux builds only - I realy believe this is
something on build compiling etc., as it is *not* happening in Windows builds.
* And it's a real memory hog, if someone like me uses many linked images every
(re-)load of a document burdens memory, and make the system swap -> unusable.
* Meanwhile I have tested Distro spefic builds of 2.0.3 (Suse, Mandriva, Ubuntu)
and there it does not happen.

So, feel free to contact me for further verification. I will appreciate!
Thanks, Alex
Comment 5 frank.meies 2006-11-01 21:35:06 UTC
FME->OD: Didn't you discuss this issue with MBA recently?
Comment 6 Mathias_Bauer 2007-12-03 14:44:51 UTC
target 3.0
Comment 7 Oliver-Rainer Wittmann 2008-04-28 11:30:14 UTC
Due to limited resources re-target to OOo 3.x
Comment 8 alex69 2008-09-24 22:02:04 UTC
after seen the reassigns checked current 2.4.1 official Linux rpms
seems behavior is *not existing* or *not significant* anymore
will check 3.0 RC hopefully next days

in detail:
if opening a document like example from i59688 or my own one the amount of
memory used for showing linked images is limited (significantly):
- on opening document no memory effect
- by browsing up to max. 80 - 100 MByte used, some times bit more but always
reduced in system monitor after some seconds (so seems OOo now on Linux builds
manages efficiently memory for linked images); this is the case for both, layout
mode and page preview mode
- at max soffice.bin used ~300 MByte at all 
- *only thing* that maybe the case that this (little) amount of memory for
images (like a cache) are not freed at documents close; this seems as a certain
amount of extra memory stays used after closing the document - but which is
difficult to judge as may be normal behavior of the caching algorithm
- think also no problem any more as if i do open several copies of the used
document to allocate more memory and see if it frees after closing (actual done
5 copies opened) it it's memory usage is 10% surplus (330 MByte) and after
closing documents memory is freed (leaving 260 Mbyte used)

summary: no significant negative effect could be reproduced

Platform: OpenSuse 10.3, i686, 32 bit, OOo 2.4.1 rpms 
Comment 9 Marcus 2017-05-20 11:17:36 UTC
Reset assigne to the default "issues@openoffice.apache.org".