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)
Version:
(earliest affected)
5.1.0.3 release
Hardware: All Windows (All)
: high major
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard:
Keywords: haveBacktrace, perf
Depends on:
Blocks:
 
Reported: 2016-05-10 14:49 UTC by Gaétan RYCKEBOER
Modified: 2017-06-17 16:56 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


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

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 5.1.0.3

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: 5.2.0.0.alpha1+
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 (CIB) 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 
Version: 6.0.0.0.alpha0+
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 )