https://bugs.documentfoundation.org/show_bug.cgi?id=172902
Bug ID: 172902
Summary: Headless image-heavy document: graphic memory grows
O(n) since 24.8 (was O(1))
Product: LibreOffice
Version: 24.8.0.3 release
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: graphics stack
Assignee: [email protected]
Reporter: [email protected]
Created attachment 207863
--> https://bugs.documentfoundation.org/attachment.cgi?id=207863&action=edit
High count and heavy raster images document
Converting an image-heavy .odt headless (soffice --headless --convert-to, also
storeToURL via UNO) uses memory that grows roughly linearly with the number of
embedded images since LibreOffice 24.8. Up to 24.2 it stayed flat regardless of
image count, so large documents that used to convert fine now exhaust RAM.
How to reproduce:
-Take an .odt with many embedded raster images (full-page images stress the
graphic
manager the most) -- attaching a 300-image sample (gen_300.odt).
- Convert it headless:
soffice --headless --convert-to pdf gen_300.odt
- check the peak RSS, e.g.:
/usr/bin/time -v soffice --headless --convert-to pdf gen_300.odt 2>&1 | grep
"Maximum resident"
(numbers below use cgroup v2's memory.peak, any peak-RSS sampler shows the same
shape)
What I measured (official TDF .deb builds, PDF v0 export, same document each
time):
24.2.7: 236 MB @20 images, 1023 MB @200 images, 978 MB @300 images -- O(1)
24.8.0.3: 238 MB @20 images, 1392 MB @200 images, 2034 MB @300 images -- O(n)
26.2.4: 239 MB @20 images, 1393 MB @200 images, 2036 MB @300 images -- O(n)
24.2.7 plateaus around 1 GB regardless of size. 24.8.0.3 -- the first 24.8
release --
already peaks at close to double that, same as current 26.2.4.
Current behavior: memory keeps growing for the whole conversion, unbounded by
image
count.
Expected behavior: memory should plateau once a threshold is reached, with idle
graphics swapped out (as up to 24.2).
--------------------------------------------------------------------
Below is what I found digging into the source, for whoever picks this up.
--------------------------------------------------------------------
Regression range and root cause:
24.2.7 is bounded, 24.8.0.3 (the first public 24.8 release) is already affected
--
confirmed both by measurement and by git history (GitHub mirror): the commit
below
is a strict ancestor of libreoffice-24.8.0.1 and unreachable from
libreoffice-24.2.7.2.
Diff of vcl/source/graphic/Manager.cxx between those tags: in 24.2,
Manager::registerGraphic reduces memory synchronously once the used size
crosses a
threshold:
void Manager::registerGraphic(const std::shared_ptr<ImpGraphic>& pImpGraphic)
{
if (mnUsedSize > mnMemoryLimit) // 300 MB
reduceGraphicMemory(aGuard); // swap idle graphics out to disk,
inline
mnUsedSize += getGraphicSizeBytes(...);
}
After the rewrite into a generic MemoryManager/MemoryManaged, registerObject()
only
adds the object and bumps mnTotalSize -- it no longer calls reduceMemory().
Reduction
now only happens via the swap-out timer, which never fires in a headless
conversion
(no event loop), so images just accumulate.
Commit: 324f2e135427f2f24cf7eb9a4fab4aa903329ae5, 2024-03-17, "vcl: change
(graphic)
Manager into a general memory manager"
(https://gerrit.libreoffice.org/c/core/+/164958). Landed on master between 24.2
and 24.8.
--
You are receiving this mail because:
You are the assignee for the bug.
