Created attachment 124955 [details]
Error popup + diags, stack and perf graphs
Reproductible in every release from at least 126.96.36.199
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.
When the OS kernel is not able to allocate some more memory, draw pops up a osl::create::Thread failed
The leak seems larger if the object allocated size is bigger, in Options - Memory settings.
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: 188.8.131.52.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)
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.
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.
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.
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.
(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.
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.
(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.
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)
Gaetan: Do you have the LO doc for comment 5 somewhere instead of the png file?
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.
Still up. This bug should be considered as critical :
- all LO Draw users under windows are concerned by this bug.
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.
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 )