Bug 126808 - UI: Writer crashes opening the style edit window after doing many style edits
Summary: UI: Writer crashes opening the style edit window after doing many style edits
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.3.0.4 release
Hardware: All Windows (All)
: high major
Assignee: Miklos Vajna
URL:
Whiteboard: target:6.4.0 target:6.2.7 target:6.3.1
Keywords: bibisected, bisected, regression
Depends on:
Blocks: GDI-Limit
  Show dependency treegraph
 
Reported: 2019-08-10 06:56 UTC by Jon Grossart
Modified: 2019-08-15 17:33 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Screencap of ProcExp at time of crash (561.93 KB, image/jpeg)
2019-08-11 20:27 UTC, Jon Grossart
Details
WinDBG Log at time of crash (1.33 KB, text/plain)
2019-08-11 20:28 UTC, Jon Grossart
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jon Grossart 2019-08-10 06:56:32 UTC
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
Comment 1 Jon Grossart 2019-08-10 07:00:27 UTC
I never saw this error on <= 6.2.x, so it seems to be a regression.
Comment 2 Mike Kaganski 2019-08-10 07:54:18 UTC
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!
Comment 3 Jon Grossart 2019-08-10 08:12:41 UTC
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.
Comment 4 Julien Nabet 2019-08-10 14:48:47 UTC
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.
Comment 5 Jon Grossart 2019-08-11 01:23:37 UTC
@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.
Comment 6 Mike Kaganski 2019-08-11 07:58:46 UTC
(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
Comment 7 Jon Grossart 2019-08-11 19:23:12 UTC
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
Comment 8 Jon Grossart 2019-08-11 19:25:18 UTC
I should have said, the link provided in the wiki is outdated. The link to the wiki is still correct.
Comment 9 Jon Grossart 2019-08-11 20:27:44 UTC
Created attachment 153306 [details]
Screencap of ProcExp at time of crash
Comment 10 Jon Grossart 2019-08-11 20:28:08 UTC
Created attachment 153307 [details]
WinDBG Log at time of crash
Comment 11 Jon Grossart 2019-08-11 20:38:33 UTC
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
Comment 12 Mike Kaganski 2019-08-12 06:37:16 UTC
(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.
Comment 13 Mike Kaganski 2019-08-12 08:26:09 UTC
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.
Comment 15 Xisco Faulí 2019-08-12 09:44:16 UTC
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
Comment 16 Xisco Faulí 2019-08-12 09:55:06 UTC
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
Comment 17 Xisco Faulí 2019-08-12 10:30:15 UTC
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
Comment 18 Miklos Vajna 2019-08-12 11:59:06 UTC
Let me try to reproduce this, thanks for the GDI leak hint.
Comment 19 Miklos Vajna 2019-08-12 14:55:42 UTC
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.
Comment 20 Commit Notification 2019-08-12 19:16:00 UTC
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.
Comment 21 Jon Grossart 2019-08-14 08:05:11 UTC
Is this going to be backported to 6.3? It's a lurking crash in any extended editing session.
Comment 22 Julien Nabet 2019-08-14 08:14:48 UTC
(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/
Comment 23 Xisco Faulí 2019-08-14 10:04:37 UTC
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!
Comment 24 Commit Notification 2019-08-14 10:08:38 UTC
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.
Comment 25 Commit Notification 2019-08-14 10:08:49 UTC
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.
Comment 26 Jon Grossart 2019-08-15 17:33:58 UTC
Great..thanks!