Steps to Reproduce: 1) open up a writer document 2) make many style edits [I was repeatedly editing the Header 1-10 suboptions] 3) open and close the style edit window each time Actual Results: Writer crashes with a popup window saying: LibreOffice 6.3 Fatal Error Could not create system bitmap! Expected Results: Writer should not crash and open up the style editing window. Build Date & Hardware: Version: 6.3.0.4 (x64) Build ID: 057fc023c990d676a43019934386b85b21a9ee99 CPU threads: 16; OS: Windows 10.0; UI render: GL; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded
I never saw this error on <= 6.2.x, so it seems to be a regression.
Does it suggest sending a crash report after the crash? If so, could you please send one, and put a link to it here for the reference? Thank you!
It doesn't suggest anything. It just pops up with the dialog and then Writer goes down. I think it's a rather low level crash. I had it happen 2 times in about 1 hour of playing with the styles.
Without a step by step process to reproduce this, it's quite difficult to help here. You can try this too: https://wiki.documentfoundation.org/QA/FirstSteps but if it crashes after 1 hour of editing, it means it may be not easy to reproduce this.
@Julien Nabet, it wasn't a really an hour of direct editing. I was doing a lot of comparison between the styles in two documents (which is a different bug I need to file since you can't preview both styles simultaneously). I did find one thing in testing though, but I'm not sure if it's the same problem or not, but if you just keep a document open and keep open and closing the modify style box, the soffice.bin Virtual Memory Private Bytes (using MS Sysinternals procexp) just keeps tending up over time, even though nothing is being changed in the document. It increases by about 100 MB every time 10 times I open a style window. Maybe the UI windows isn't being destroyed correctly? This could be leading to the seeming Windows system crash if some part of the process runs out of memory for a new window after a longer editing session. This also happens just opening and closing a document repeatedly.
(In reply to Jon Grossart from comment #5) Please take a look at [1] to see if you can possibly create a minidump of the crash; it would be really helpful to be able to debug this interesting problem. Thanks! [1] https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg
I'll try it when I have some time. Note your link is outdated and it's now at: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools
I should have said, the link provided in the wiki is outdated. The link to the wiki is still correct.
Created attachment 153306 [details] Screencap of ProcExp at time of crash
Created attachment 153307 [details] WinDBG Log at time of crash
I was able to create the crash again. There is no shortcut, you just have to open and close a ton of dialogs until something stops working. It would probably happen faster on a system with lower memory (I have 32 GiB). It might be possible to record a macro to open and close the style window multiple times to save on clicks. WinDbg showed no exception at the time of crash, just a ton of runtime exceptions that scroll basically any time you do anything in the program, but the debugger doesn't stop then. (2b04.1f44): C++ EH exception - code e06d7363 (first chance) When the crash happened, the bugger did stop, but no real information showed up in the analaysis. However, proc explorer does show some interesting things: 9932 GDI handles -- when you start LibO with the same document opened I was testing with, it shows 138 handles. I don't think having 2 documents open should eventually end up with 2 GB of working RAM with 8 GB of virtual size. Active RAM also went from 260 MB to 512 M MB over the time of debugging. There is clearly some form of memory leak happening. For reference, just opening the same two documents with no editing: Private Bytes: 421 MB Peak Private: 1.15 GB Virtual Size: 5.25 GB Working Set: 260 MB Hangles: 6559 GSI Handles: 178 USER Handlers: 229
(In reply to Jon Grossart from comment #11) > 9932 GDI handles -- when you start LibO with the same document opened I was > testing with, it shows 138 handles. I think you've found the crash cause... we need to check if GDI handles indeed not released in the dialogs open/close scenario and bibisect that.
Confirmed with Version: 6.3.0.4 (x64) Build ID: 057fc023c990d676a43019934386b85b21a9ee99 CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded Every open-close cycle of a paragraph style dialog (right-click at a style in the sidebar, and choose Modify; then click Cancel) increases total GDI handle use count by 100. Increasing importance for CRASHER regression.
Searching about fixes of GDI leaks, I found this kind of commits: https://cgit.freedesktop.org/libreoffice/core/commit/?id=289711c2a469bfbe06aef3b3870b65f9c788f56d So Opengroking, https://opengrok.libreoffice.org/search?project=core&full=%22VclPtr%3CVirtualDevice%3E%3A%3ACreate%28%29%22&defs=&refs=&path=svx&hist=&type=&si=path Perhaps other locations should be changed (eg: https://opengrok.libreoffice.org/xref/core/svx/source/svdraw/svdhdl.cxx?r=06daea73#1179) in the same way?
GDIVIEW is a good tool for checking the GDIs used < https://www.nirsoft.net/utils/gdi_handles.html > Every time I open the paragraph dialog, ~100 are created and not released, eventually it should crash if 10.000 is reached
GDI are released after closing the dialog in Versión: 5.3.7.2 Id. de compilación: 6b8ed514a9f8b44d37a1b96673cbbdd077e24059 Subprocs. CPU: 1; SO: Windows 6.1; Repres. IU: predet.; Motor de trazado: HarfBuzz; Configuración regional: es-ES (es_ES); Calc: group
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=d4714b0fdb81e6e561ae526cc517ecc9a40a603e author Miklos Vajna <vmiklos@collabora.com> 2019-06-17 17:02:54 +0200 committer Miklos Vajna <vmiklos@collabora.com> 2019-06-17 19:08:43 +0200 commit d4714b0fdb81e6e561ae526cc517ecc9a40a603e (patch) tree e02901728616ef7ab881c09c8a4c6b397e6f7a89 parent 2be2c914ed48823304c2e95a836ee93a08853628 (diff) tdf#101978 vcl combobox/listbox floating window: avoid flicker Bisected with: bibisect-win64-6.4 Adding Cc: to Miklos Vajna
Let me try to reproduce this, thanks for the GDI leak hint.
Yes, I can reproduce. Note that the majority (but not all) leaks are caused by the above flicker-related commit. Here are some numbers I get: bad: 163 -> 205 -> 247 good: 118 -> 121 -> 122 I'll look at how to get back to the rather slow rate from the current fast rate.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/e71093c0bc52426647a9d3a41ac0643bbc6cb0c6%5E%21 tdf#126808 vcl: fix crash due to leaking the frame's buffer vdev It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Is this going to be backported to 6.3? It's a lurking crash in any extended editing session.
(In reply to Jon Grossart from comment #21) > Is this going to be backported to 6.3? It's a lurking crash in any extended > editing session. Backport on 6.3 branch done by Xisco waiting for review here: https://gerrit.libreoffice.org/#/c/77389/
Verified in Version: 6.4.0.0.alpha0+ (x64) Build ID: 744f70386727c78a19bd7c1de7425392b98783c7 CPU threads: 16; OS: Windows 6.3; UI render: default; VCL: win; Locale: en-GB (en_GB); UI-Language: en-US Calc: threaded @Miklos, thanks for fixing this issue!
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-6-2": https://git.libreoffice.org/core/+/ad372e603547d54ab28271d89adc45250368a248%5E%21 tdf#126808 vcl: fix crash due to leaking the frame's buffer vdev It will be available in 6.2.7. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/+/33258dfc3b97fd357273c52d9c7c9854362e25b6%5E%21 tdf#126808 vcl: fix crash due to leaking the frame's buffer vdev It will be available in 6.3.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Great..thanks!