Bug 99763 - Memory leaks when creating, moving, editing and deleting objects
Summary: Memory leaks when creating, moving, editing and deleting objects
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
(earliest affected) release
Hardware: All Windows (All)
: high major
Assignee: Not Assigned
Keywords: haveBacktrace, perf
Depends on:
Blocks: Memory
  Show dependency treegraph
Reported: 2016-05-10 14:49 UTC by Gaétan RYCKEBOER
Modified: 2021-01-11 03:58 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

Error popup + diags, stack and perf graphs (199.37 KB, image/png)
2016-05-10 14:49 UTC, Gaétan RYCKEBOER
Complex diagram done with draw (559.98 KB, image/png)
2016-06-01 09:08 UTC, Gaétan RYCKEBOER
Heap extract from faulty process - VMMap (111.98 KB, image/png)
2016-06-01 09:54 UTC, Gaétan RYCKEBOER
Sample ODG with VRT objects (49.75 KB, application/vnd.oasis.opendocument.graphics)
2016-07-19 07:41 UTC, Gaétan RYCKEBOER

Note You need to log in before you can comment on or make changes to this bug.
Description Gaétan RYCKEBOER 2016-05-10 14:49:53 UTC
Created attachment 124955 [details]
Error popup + diags, stack and perf graphs

Reproductible in every release from at least

At least every 10 minutes of use.

After a time of use, the software uses a bunch of memory. It increases at each operation (move, edit, create or delete an object).

I tried to reduce the undo level : no success.
I tried to change the memory settings : no success. It seems like a memory leak.

Windows 8.1 pro, x64, 8GiB RAM.
Comment 1 Gaétan RYCKEBOER 2016-05-11 07:27:23 UTC
When the OS kernel is not able to allocate some more memory, draw pops up a osl::create::Thread failed
Comment 2 Gaétan RYCKEBOER 2016-05-11 10:21:08 UTC
The leak seems larger if the object allocated size is bigger, in Options - Memory settings.
Comment 3 Buovjaga 2016-05-17 13:56:02 UTC
I reproduce.

I used it for some minutes, creating objects, moving, editing and deleting them randomly.
Memory consumption rose from 50M to 56M very gradually. Deleting all objects did not make it return to the original level.

Win 8.1 32-bit
LibreOffice Version:
Build ID: cc1a0ba927ad6f85103059aa8e6108017f436304
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; 
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-05-17_02:31:19
Locale: fi-FI (fi_FI)
Comment 4 Gaétan RYCKEBOER 2016-05-18 08:35:52 UTC
The length of use have no impact on the memory consumption. The memory allocation eventualy conduct the app to an inevitable crash.

It crashes even if unused for hours.

If the user uses complex objects, as found in libraries for instance, the crash occurs really sooner (draw is able to eat more than 1GiB in a couple of minutes)

This is a major bug.
Comment 5 Gaétan RYCKEBOER 2016-06-01 09:08:18 UTC
Created attachment 125436 [details]
Complex diagram done with draw

This is a diagram wich cause draw to crash too often to make it really useful.
Comment 6 Gaétan RYCKEBOER 2016-06-01 09:09:03 UTC
On certain documents (with multiple pages, mask and complex objects such as network infrastructure design), it crashes up to every 10mn.

It makes it totally useless as a MS Visio replacement, which is really a pity, as Draw is nearly the only alternative to the Microsoft commercial defacto standard.

Priority should be granted to high : “Serious problems/Inability to open certain documents/Tediously slow.  Affects many users.”

It affects every user who wants to do more than a graffiti on the corner of a desk.
Comment 7 Gaétan RYCKEBOER 2016-06-01 09:29:07 UTC
The memory grows quicker for moves than for copy/paste.
The memory remains high, even if the files are all closed.

Is there a way to analyse memory objects remaining, when all files are closed ? How to inspects memory affected to Draw ?

I would really help debugging this if possible.
Comment 8 Buovjaga 2016-06-01 09:38:34 UTC
(In reply to Gaétan RYCKEBOER from comment #7)
> The memory grows quicker for moves than for copy/paste.
> The memory remains high, even if the files are all closed.
> Is there a way to analyse memory objects remaining, when all files are
> closed ? How to inspects memory affected to Draw ?
> I would really help debugging this if possible.

On Windows, DrMemory is an option for this: https://wiki.documentfoundation.org/Development/How_to_debug#Searching_for_a_memory_corruption_on_Windows_using_DrMemory

Devs told me it reports leaks as well as crashes.
Comment 9 Gaétan RYCKEBOER 2016-06-01 09:54:14 UTC
Created attachment 125442 [details]
Heap extract from faulty process - VMMap

This is an extract of the memory. The leak is in the heap, private memory.

You would be able to notice the size of the blocks, quite all on the same heap (#4).

I don't know how to give ways to find the faulty disposer of memory heap blocks.
Comment 10 Gaétan RYCKEBOER 2016-06-01 10:14:43 UTC
(In reply to Buovjaga from comment #8)
> Devs told me it reports leaks as well as crashes.

Error #2: LEAK 168 direct bytes 0x023c7928-0x023c79d0 + 0 indirect bytes
# 0 replace_RtlAllocateHeap               [d:\drmemory_package\common\alloc_replace.c:3770]
# 1 KERNELBASE.dll!LocalAlloc            +0x85     (0x74954306 <KERNELBASE.dll+0x14306>)
# 2 SHCORE.dll!CommandLineToArgvW        +0x97     (0x722768f8 <SHCORE.dll+0x168f8>)
# 3 soffice.exe!?                        +0x0      (0x00c71873 <soffice.exe+0x1873>)
# 4 soffice.exe!?                        +0x0      (0x00c7203c <soffice.exe+0x203c>)
# 5 KERNEL32.dll!BaseThreadInitThunk     +0x23     (0x76197c04 <KERNEL32.dll+0x17c04>)

Potential Error #2: HANDLE LEAK: KERNEL handle 0x000001e4 and 0 similar handle(s) were opened but not closed:
# 0 system call NtOpenKey          
# 1 KERNEL32.dll!CreateActCtxWWorker             +0x1873   (0x761968e4 <KERNEL32.dll+0x168e4>)
# 2 KERNEL32.dll!BaseCheckAppcompatCacheExWorker +0x4f9    (0x76194baa <KERNEL32.dll+0x14baa>)
# 3 KERNEL32.dll!BaseCheckAppcompatCacheExWorker +0x5e     (0x7619470f <KERNEL32.dll+0x1470f>)
# 4 KERNEL32.dll!BasepCheckBadapp                +0x143    (0x76199e84 <KERNEL32.dll+0x19e84>)
# 5 KERNEL32.dll!BasepQueryAppCompat             +0xb8     (0x76199c99 <KERNEL32.dll+0x19c99>)
# 6 KERNELBASE.dll!CreateProcessInternalW        +0xb49    (0x7496a86a <KERNELBASE.dll+0x2a86a>)
# 7 KERNELBASE.dll!CreateProcessW                +0x2b     (0x74969d0c <KERNELBASE.dll+0x29d0c>)
# 8 soffice.exe!?                                +0x0      (0x00c71927 <soffice.exe+0x1927>)
# 9 soffice.exe!?                                +0x0      (0x00c7203c <soffice.exe+0x203c>)
#10 KERNEL32.dll!BaseThreadInitThunk             +0x23     (0x76197c04 <KERNEL32.dll+0x17c04>)
Note: @0:07:39.632 in thread 4352

Total : 660 bytes counted, but in reality, more than 300MiB leaked.

I presume DrMemory didn't found the right problem.
Comment 11 Julien Nabet 2016-06-19 08:47:51 UTC
Armin/Thorsten: thought you might be interested in this one.

Thank you Gaétan for all these interesting attachments! I'm pretty sure you may help a lot on Windows only bugs with such analysis!
If interested in dev contributing, you may read this https://wiki.documentfoundation.org/Development and as a start, building LO from sources (see https://wiki.documentfoundation.org/Development/BuildingOnWindows)
Comment 12 Armin Le Grand 2016-07-07 11:49:47 UTC
Gaetan: Do you have the LO doc for comment 5 somewhere instead of the png file?
Comment 13 Gaétan RYCKEBOER 2016-07-19 07:41:05 UTC
Created attachment 126293 [details]
Sample ODG with VRT objects

I dont. But I could give you another one, built the same way as the first one.
Comment 14 Gaétan RYCKEBOER 2016-10-04 10:05:43 UTC
Still up. This bug should be considered as critical :
- all LO Draw users under windows are concerned by this bug.
Comment 15 Daniel Hoffend 2016-10-21 20:35:50 UTC
I can confirm this problem! I experienced various Libreoffice Draw crashes while working on network infrastructure diagrams.

It was extremely annoying when I was using VRT network shapes inside the document, then it crashed every 10-30 minutes.

Doing normal cabling plans (just with rectangles and connectors) didn't crashed draw, but as soon as I was inserting VRT shapes everything got very unstable.

Most of the time even the autosave function didn't saved my work (so I was constantly pressing ctrl+s for the save shortcut.

IMO this is a major drawback and critical bug.
Comment 16 Telesto 2017-06-17 16:56:11 UTC
The large scale memory leaking seems to be fixed 
Build ID: cbf371e07fd5dea1ea08a1f299360d1273961ebd
CPU threads: 4; OS: Windows 6.19; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-06-14_23:13:57
Locale: nl-NL (nl_NL); Calc: CL

However I'm still seeing smaller and large leaks. Especially when keeping the same document open for a long period of time while editing in small steps and saving regularly (manual save; but auto-save should have the same effect)

40 Mb increase every time
1. Open attachment 126293 [details]
2. Go to master pages
3. Copy the content of Page 1 (CTRL+A CTRL+C)
4. Create a new master page and paste it.
5. Switch back to Normal View; paste the same content again on a page
6. Save (40 MB added)
7. Remove the pasted content
8. Repeat step 2-7.

Closing the document will free most of the memory. Random moving, pasting, copying objects does work too, but isn't that effective anymore (mostly a couple mb's )
Comment 17 QA Administrators 2018-06-18 02:42:04 UTC Comment hidden (obsolete)
Comment 18 Gaétan RYCKEBOER 2018-06-18 11:37:07 UTC
Still present.
Build ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf
CPU threads: 4; OS: Windows 6.1; UI render: default;
Comment 19 Telesto 2018-06-18 16:49:48 UTC
Still some leaking, but improved (as far I can tell), with
Build ID: 51aa57cd8ed46d28262e0d315328231f0fa814f4
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-06-12_05:54:56
Locale: nl-NL (nl_NL); Calc: CL

Steps to create some leaking
1. Open attachment 126293 [details]
2. Switch to Master view (notice a memory bump)
3. Copy the items
4. Paste them on a new sheet in normal view
5. Save the file (CTRL+S) (
6. Close (grey cross)
7. Reopen the file
8. Repeat 2-6 a few times.
Comment 20 QA Administrators 2021-01-11 03:58:07 UTC
Dear Gaétan RYCKEBOER,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team