https://bugs.documentfoundation.org/show_bug.cgi?id=115420
--- Comment #33 from Mike Kaganski <mikekagan...@hotmail.com> ---
(In reply to Jan-Marek Glogowski from comment #30)
> From the backtrace I guess we schedule an flush on the dialog, which is gone
> at this point.
The OpenGLFlushIdle object for the crashing operation is created long before
the WinSalFrame is destroyed.
I have put action breakpoints to both OpenGLFlushIdle constructor, and
WinSalFrame destructor, that would output the frame's pointer address to
console. Then I started the debug according to steps in bug 115975; closed the
confirmation dialog using "Cancel"; and got the crash. I have examined the
console output to see a number of OpenGLFlushIdle objects that got constructed
prior to the destruction of that WinSalFrame which was used afterwards in the
crashing flush.
Next, to see if there might have been some async console output that could
reorder the lines, I did the same again; but this time, before hitting the
"Cancel" in confirmation, I switched to VS, and cleared the console. Then I
returned and clicked "Cancel", and got the crash. This time, console only
contained the dtor line, without any prior creation of OpenGLFlushIdle objects
(that, obviously, were created even before clearing the debug console).
I am not familiar with this corner of the code; so I don't know where to look
now. But it looks like some idle processing hasn't happened in the lifetime of
the dialog.
If this helps, we could arrange a desktop sharing to debug this on my system.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
