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 )
** Please read this message in its entirety before responding **
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 http://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!
Build ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf
CPU threads: 4; OS: Windows 6.1; UI render: default;
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.