Bug 391223 - enormous memory leaks when viewing rtf documents
Summary: enormous memory leaks when viewing rtf documents
Status: RESOLVED FIXED
Alias: None
Product: calligrawords
Classification: Applications
Component: okularplugin (show other bugs)
Version: unspecified
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Friedrich W. H. Kossebau
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-28 13:06 UTC by qptain Nemo
Modified: 2021-02-18 16:55 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
an example file as requested (44.92 KB, application/vnd.oasis.opendocument.text)
2018-02-28 19:36 UTC, qptain Nemo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description qptain Nemo 2018-02-28 13:06:15 UTC
When viewing an rtf file, Okular allocates approximately 100 mb of RAM per one scrolled line of text.
Comment 1 Nate Graham 2018-02-28 18:50:41 UTC
Can you attach the file in question?

Also, is this a true "leak"? Leaking would be if the memory continuously rises over time. If Okular allocates a lot of memory initially, but then it stays static, that's not a leak.
Comment 2 qptain Nemo 2018-02-28 19:10:39 UTC
It works with any rtf file I try, regardless of the source. What seems to be the trigger however is hiding the panels with the thumbnails. As soon as I click on the thumbnail icon and the panel is hidden with the text taking the vast majority of the window the rate at which memory is allocated becomes truly absurd, again, scrolling by a mere line of text in either direction (even back and forth) spends a couple hundred megabytes each time. Opening the panel again stops the wastage of memory but doesn't free what has already been wasted.

It seems to affect odt files as well but not pdf.
Comment 3 Nate Graham 2018-02-28 19:14:36 UTC
I still need you to attach the file that causes this, because I'm not able to reproduce with any of the RTFs that I have lying around.

Also, could you please re-phrase in the form of a detailed Steps to Reproduce? See https://community.kde.org/Get_Involved/Bug_Reporting#Steps_to_Reproduce

It's a little hard to tell what I should do to make this happen.
Comment 4 qptain Nemo 2018-02-28 19:36:42 UTC
Created attachment 111096 [details]
an example file as requested
Comment 5 qptain Nemo 2018-02-28 19:38:30 UTC
Very well, here is an odt file produced by copying a part of a Wikipedia article into LibreOffice Write and saving it as an odt document. To reproduce the bug, open this file in Okular and hide the navigation panel by selecting Settings -> Show Navigation Panel in the main menu of the program.
Comment 6 Nate Graham 2018-02-28 19:46:28 UTC
That's an ODT document, not an RTF. You can reproduce the issue with this ODT file as as well as the original RTF?

Even with that document, I'm unable to reproduce the issue on my KDE Neon machine with Plasma and Okular from git master. Okular only ever uses a maximum of 31 MB of RAM when I scroll through it after hiding the navigation panel as requested and using otherwise default settings.

Do you have Okular's memory usage set to Greedy, out of cusiosity? (Settings > Configure Okular > Performance)

Even then, I could only get Okular to consume 67 Mb of RAM with the supplied document.
Comment 7 qptain Nemo 2018-02-28 19:51:09 UTC
Yes, I can.

This is strange and concerning. I'm on Arch running Xfce. 

And no, the memory usage is set to Normal.
Comment 8 Albert Astals Cid 2018-02-28 23:04:01 UTC
there's two different odt backends, one that comes with okular itself and one that comes with calligra, can you both check which version are you using?

A way to do it is

grep generator /proc/`pidof okular`/maps

when you have opened the odt file with okular
Comment 9 qptain Nemo 2018-02-28 23:16:59 UTC
Sorry but what package does the generator command come from?
Comment 10 qptain Nemo 2018-02-28 23:20:22 UTC
Nevermind, figured it out. Looks like I'm using the calligra backend.
Comment 11 Albert Astals Cid 2018-02-28 23:21:44 UTC
(In reply to qptain Nemo from comment #10)
> Nevermind, figured it out. Looks like I'm using the calligra backend.

Can you please paste the output of that grep command i wrote?
Comment 12 qptain Nemo 2018-02-28 23:22:51 UTC
$ grep generator /proc/`pidof -s okular`/maps
7f8017e59000-7f8017e5c000 r-xp 00000000 08:02 144314188                  /usr/lib/qt/plugins/okular/generators/okularGenerator_odt_calligra.so
7f8017e5c000-7f801805b000 ---p 00003000 08:02 144314188                  /usr/lib/qt/plugins/okular/generators/okularGenerator_odt_calligra.so
7f801805b000-7f801805c000 r--p 00002000 08:02 144314188                  /usr/lib/qt/plugins/okular/generators/okularGenerator_odt_calligra.so
7f801805c000-7f801805d000 rw-p 00003000 08:02 144314188                  /usr/lib/qt/plugins/okular/generators/okularGenerator_odt_calligra.so
Comment 13 Albert Astals Cid 2018-02-28 23:30:03 UTC
Moving to calligra
Comment 14 Albert Astals Cid 2018-02-28 23:30:23 UTC
Calligra devels this is for you
Comment 15 Pierre Ducroquet 2021-02-18 16:46:19 UTC
Indeed, I can reproduce the issue. It only affects the okular plugin.
Comment 16 Pierre Ducroquet 2021-02-18 16:55:39 UTC
Fix, thanks for the report!

https://invent.kde.org/office/calligra/commit/3e3b602aff077e189d2d38826f38fcc8a9e1e486