Created attachment 139546 [details]
Crash dump

Do you reproduce this if you disable OpenGL?(see https://wiki.documentfoundation.org/QA/FirstSteps)

If no, could you attach <user profile>/cache/opengl_device.log ? (see the same link)

Finally, could you check you got the last drivers of your graphic card?

Created attachment 139547 [details]
Open GL device log

Disabling Open GL solve this problem

Created attachment 139548 [details]
Last open GL log with last driver from NVidia

Updating NVidia driver doesn't solve this problem.

With crashreports, let's put this one to NEW.

I submitted a patch for review here:
https://gerrit.libreoffice.org/#/c/49186/
It's more a workaround since it blacklists this graphic card for OpenGL use in LO.
I don't know if it's the right thing to do, that's why I'll wait for LO dev experts respond.

Hi,
So, we can't use OpenGL with LibreOffice with these pretty good video card ?
I hope you will find what it crash with these type of video card.
Thanks in advance.
Best regards

Meanwhile for the test, and if you got some time, could you give a try to a daily master build http://dev-builds.libreoffice.org/daily/master/Win-x86@42/current/ ?
Indeed, some threading/timer part may have been fixed which may help here.

Created attachment 139557 [details]
OpenGL Device log file

I had to add Grammalecte-fr-v0.5.17 extension to verify update, LibreOffice crash again

(In reply to JdTissot from comment #10)
> I had to add Grammalecte-fr-v0.5.17 extension to verify update, LibreOffice
> crash again

You mean with OpenGL disabled or still with OpenGL enabled?

With OpenGL enabled

*** Bug 115628 has been marked as a duplicate of this bug. ***

Created attachment 139799 [details]
LO 6.0.1.1 OpenGL device log Intel HD Graphics 620 on Windows 10 Home ver 1709 64-bit

OpenGL device log as requested...

I let the patch on review but since I know too little about OpenGL, I'll put back the status to NEW.
I tried to get some help here http://nabble.documentfoundation.org/Questions-about-OpenGL-tt4232284.html but had no feedback.

Created attachment 140008 [details]
windbg-64 StackTrace of Crashing LO6.0.1.1 on close of Extension Manager check for update

Had WinDbg-64 open and attached to soffice.bin; with OpenGL rendering enabled and while running the Extension Manager -> Check for Updates. Either Wiki publisher or English spelling dictionaries.

When no updates are found -- a click on the "Close" button crashes to recovery.

Interesting that if instead the frame is dismissed with the CSD "X" button--no crash.

And, when OpenGL is disabled, a click on the "Close" button of the check for updates does not crash.

=-=-= 

crashreport.libreoffice.org/stats/crash_details/cd449448-692b-4efa-b9a6-961281d54850

crashreport.libreoffice.org/stats/crash_details/340f1973-7a96-437f-bbd2-5bc429feb54e

*** Bug 115764 has been marked as a duplicate of this bug. ***

In my case the error is reproducible with opengl enabled and disabled.

Only runing libreoffice in safe mode seems to work.

Tested with opengl enabled -> steps to crash -> crash

restarted Libreoffice.

disable opengl in the options

close libreoffice

restart the machine (paranoid much?)

start libreoffice

check if the opengl option is still disabled -> it is.

check if crash occurs -> crash.

If matters, my card is an AMD radeon R9 390, 8 Gb vram.

@Telesto, @V Stuart, any change it can be bisected?

@Michael M.--See the debug trace from Comment 16, the crash here really only occurs with OpenGL rendering enabled. Why drop it from the META?

Oh - I was rather convinced by comment#18 =) Its great to see the trace there ! should make things much easier ... nice work.

(In reply to Xisco Faulí from comment #19)
> @Telesto, @V Stuart, any change it can be bisected?

Crash on "Close" button click with OpenGL enabled, bibisect from builds on hand:

https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=a9588baca8137f51e2ca72e40b1f448b0e1885d1..1e87e93132f808ab95eab932b36bfe40d3cc607a

Bad
2017-11-03 8c374022790b54834fa54615e1953c8ee30641a8

2017-08-23 1ba1bb96659d0048bff2a9a15646f6e1e04bd2c4

2017-08-02 9ca7bda2cc8b67c2d10fcb81cce8bfd4d8b79b09

2017-07-25 1e87e93132f808ab95eab932b36bfe40d3cc607a

Good
2017-07-21 a9588baca8137f51e2ca72e40b1f448b0e1885d1

2017-07-19 c0d7f348f20ea1ae0d4b738136be4d5cbff550ae

2017-06-16 5ac1d27d0bca285047f291e0a475f8bb99134cea

Bibisected to the commit referenced below using repo bibisect-win32-6.0 (and a dictionary added to instdir/share/extensions, so Check for Updates is active in Extension Manager). For me it also only happens with OpenGL enabled. The commit seems to be earlier than some of the good ones identified by V Stuart, but I'm already getting a crash by checking out the commit corresponding to a9588baca8137f51e2ca72e40b1f448b0e1885d1's state in the bibisect repo.
Adding Cc: to Jan-Marek Glogowski, please take a look.

The crash itself occurs in:
https://opengrok.libreoffice.org/xref/core/vcl/inc/openglgdiimpl.hxx#161
bool IsOffscreen() const { return mpProvider == nullptr || mpProvider->IsOffScreen(); }

mpProvider is an invalid pointer, so this seems to be a use-after-free issue.


https://cgit.freedesktop.org/libreoffice/core/commit/?id=52dfefec8da5d7f25c39218fd890cad6491728ab
author		Jan-Marek Glogowski <glogow@fbihome.de>	2017-01-27 23:40:11 +0100
committer	Jan-Marek Glogowski <glogow@fbihome.de>	2017-07-13 12:10:27 +0200

Run LO scheduler only via system timer

(In reply to Aron Budea from comment #23)
>...
> bool IsOffscreen() const { return mpProvider == nullptr ||
> mpProvider->IsOffScreen(); }
> 
> mpProvider is an invalid pointer, so this seems to be a use-after-free issue.
>...
Either mpProvider is equal to nullptr and it returns true without testing second condition (and so without trying dereferencing nullptr)
or mpProvider != null and we enter the second condition without pb of nullptr dereferencing.

My crash report signature is different from what's indicated in the crash report field:
http://crashreport.libreoffice.org/stats/crash_details/a4ce0839-1ec7-4ad7-a7d4-68e9a91ef1cf

(In reply to Julien Nabet from comment #24)
> (In reply to Aron Budea from comment #23)
> >...
> > bool IsOffscreen() const { return mpProvider == nullptr ||
> > mpProvider->IsOffScreen(); }
> > 
> > mpProvider is an invalid pointer, so this seems to be a use-after-free issue.
> >...
> Either mpProvider is equal to nullptr and it returns true without testing
> second condition (and so without trying dereferencing nullptr)
> or mpProvider != null and we enter the second condition without pb of
> nullptr dereferencing.
Deleting an object doesn't set its pointers scattered in the code to nullptr.

(In reply to Aron Budea from comment #26)
> ...
> Deleting an object doesn't set its pointers scattered in the code to nullptr.

I agree with you but why you're talking about deleting an object here?
Indeed, https://opengrok.libreoffice.org/search?project=core&q=mpProvider&defs=&refs=&path=&hist=&type= shows no call to delete on mpProvider.

(In reply to Julien Nabet from comment #27)
> I agree with you but why you're talking about deleting an object here?
> Indeed,
> https://opengrok.libreoffice.org/
> search?project=core&q=mpProvider&defs=&refs=&path=&hist=&type= shows no call
> to delete on mpProvider.
The deletion must've happened somewhere else, since this class is not the owner of mpProvider, the pointer is passed in via the constructor.

Aron's analysis is basically right =) we invoke a virtual function call on an already deleted instance of the mpProvider - clearly the way the lifecycle of that and the management of pointers to it got messed up somewhere.

I can't reproduce this, because I'm running Windows in a KVM without OpenGL, and the crash is OpenGL related.

From the backtrace I guess we schedule an flush on the dialog, which is gone at this point.

OTOH the patch is not responsible for the crash, but it changes the timing of processing events, so that race may have been there for much longer.

I assume this can be added to VCL-OpenGL again.

*** Bug 115975 has been marked as a duplicate of this bug. ***

Anyway it looks strange that the event objects aren't ref-counted, and not interlocked for the duration of execution. The OpenGLFlushIdle object is created in OpenGLSalGraphicsImpl constructor (and is held in unique_ptr); a naked pointer to it is saved in ImplSchedulerData and put into scheduler task list, and its usage might happen after the OpenGLFlushIdle has already been destroyed.

I'd expect it behave more reliably if Task was ref-counted, and its owner would flag it disposed (but not destruct), so that scheduler knew that the task should be discarded; and the operations were guarded by a mutex (just an idea).

Hi Mike; thanks for that - a valgrind trace would perhaps show where the data was allocated - but I guess just code reading around the lifecycle of the flush handler and more to the point the mpProvider - which must get out of sync somehow and not cleanup its graphics.

Unfortunately the SalGraphics lifecycle from what I recall is -crazy- that thing is re-created and switched between Windows left & right which needs de-bonging too really but ... ;-) HTH.

*** Bug 116115 has been marked as a duplicate of this bug. ***

Presumably the OpenGLSalGraphicsImpl (and other SalGraphicsImpls too) - and its associated WinSalGraphics survives longer than the SalGeometryProvider which is either a SalFrame or a SalVirtualDevice.

Then again the apparently deranged lifecycle of SalGraphics as they relate to SalFrames etc. is something of a nightmare:

    // SalGraphics or NULL, but two Graphics for all SalFrames
    // must be returned
    virtual SalGraphics*    AcquireGraphics() = 0;
    virtual void            ReleaseGraphics( SalGraphics* pGraphics ) = 0;

So - working out what has failed to release the WinSalGraphics is probably non-trivial; particularly as the bisection is reasonably unhelpful.

Hmm - then again ... looking at the code:

vcl/win/window/salframe.cxx

It puzzles me:

WinSalFrame::~WinSalFrame()
{

    // Release Cache DC
    if ( mpGraphics2 &&
         mpGraphics2->getHDC() )
        ReleaseGraphics( mpGraphics2 );

Doesn't seem to do anything of the sort; unless mpGraphics2 == mpGraphics.

Indeed the condition:

void WinSalFrame::ReleaseGraphics( SalGraphics* pGraphics )
{
    if ( mpGraphics2 == pGraphics )
    {

Looks deeply counter-intuitive; surely that should be mpGraphics2 != pGraphics - ie. only free it if it is different ?

I'm left puzzled by who frees mpGraphics2 - which (after all) has this timer associated with it. Of course, that is not related to GL, and perhaps is a leak but only when used threaded:

    WinSalGraphics*         mpGraphics;             // current frame graphics
    WinSalGraphics*         mpGraphics2;            // current frame graphics for other threads

The rather grim extensions code being high on the awful threaded, graphical code list of horror.

Thoughts much appreciated; I append a blind fix in case someone can reproduce this and can compile that.

diff --git a/vcl/win/window/salframe.cxx b/vcl/win/window/salframe.cxx
index 64b073f99139..fee8440cc700 100644
--- a/vcl/win/window/salframe.cxx
+++ b/vcl/win/window/salframe.cxx
@@ -926,6 +926,17 @@ WinSalFrame::~WinSalFrame()
          mpGraphics2->getHDC() )
         ReleaseGraphics( mpGraphics2 );
 
+    // Why did we never do this ?
+    if (mpGraphics2 != mpGraphics)
+    {
+        if ( mpGraphics2->getDefPal() )
+            SelectPalette( mpGraphics2->getHDC(), mpGraphics2->getDefPal(), TRUE );
+        mpGraphics2->DeInitGraphics();
+        ReleaseDC( mhWnd, mpGraphics2->getHDC() );
+        delete mpGraphics2;
+        mpGraphics2 = nullptr;
+    }
+
     // destroy saved DC
     if ( mpGraphics )
     {

But quite possibly I'm confused =) it happens.

(In reply to Michael Meeks from comment #39)
> Thoughts much appreciated; I append a blind fix in case someone can
> reproduce this and can compile that.
After applying the patch, I'm getting assertion failed at startup:
"vcl/win/app/salint.cxx Line: 611

Expression: !pInst->mbNoYieldLock"

Note that I pulled ~1.5 weeks ago, so the sources aren't the freshest.

Can you get a trace for that assertion failure ? looks odd =) thanks !

(In reply to Michael Meeks from comment #39)
> Hmm - then again ... looking at the code:
> 
> vcl/win/window/salframe.cxx
> 
> It puzzles me:
> 
> WinSalFrame::~WinSalFrame()
> {
> 
>     // Release Cache DC
>     if ( mpGraphics2 &&
>          mpGraphics2->getHDC() )
>         ReleaseGraphics( mpGraphics2 );
That's fine - should be sufficient to just check for mpGraphics2, as ReleaseGraphics does the rest.

> Doesn't seem to do anything of the sort; unless mpGraphics2 == mpGraphics.
> 
> Indeed the condition:
> 
> void WinSalFrame::ReleaseGraphics( SalGraphics* pGraphics )
> {
>     if ( mpGraphics2 == pGraphics )
>     {
> 
> Looks deeply counter-intuitive; surely that should be mpGraphics2 !=
> pGraphics - ie. only free it if it is different ?
No - we just free the cached / shared / threaded DC (not the object), if we want to release it.

> I'm left puzzled by who frees mpGraphics2 - which (after all) has this timer
> associated with it. Of course, that is not related to GL, and perhaps is a
> leak but only when used threaded:
> 
>     WinSalGraphics*         mpGraphics;             // current frame graphics
>     WinSalGraphics*         mpGraphics2;            // current frame
> graphics for other threads
> 
> The rather grim extensions code being high on the awful threaded, graphical
> code list of horror.
> 
> Thoughts much appreciated; I append a blind fix in case someone can
> reproduce this and can compile that.
> 
> diff --git a/vcl/win/window/salframe.cxx b/vcl/win/window/salframe.cxx
> index 64b073f99139..fee8440cc700 100644
> --- a/vcl/win/window/salframe.cxx
> +++ b/vcl/win/window/salframe.cxx
> @@ -926,6 +926,17 @@ WinSalFrame::~WinSalFrame()
>           mpGraphics2->getHDC() )
>          ReleaseGraphics( mpGraphics2 );
>  
> +    // Why did we never do this ?
> +    if (mpGraphics2 != mpGraphics)
This is always true. Don't confuse the mpGraphics with pGraphics. I did it quite some times when reading the code.
But we seem to leak the mpGraphics2 object, which is assigned once, but never freed.

I'm now definitely preferring an *m_* prefix for member variables.

(In reply to Aron Budea from comment #40)
> (In reply to Michael Meeks from comment #39)
> After applying the patch, I'm getting assertion failed at startup:
> "vcl/win/app/salint.cxx Line: 611
> 
> Expression: !pInst->mbNoYieldLock"

Probably we need something like the fix in 4baec725e0dc0713f0d47003e9b10bc3b62f56ff here.
Seems we switch to the main thread and then to an other thread again here.
But that is just a guess.

commit 4baec725e0dc0713f0d47003e9b10bc3b62f56ff
Author: Jan-Marek Glogowski <glogow@fbihome.de>
Date:   Mon Aug 28 19:58:32 2017 +0200

    WIN run main thread redirects ignoring SolarMutex

Some patches based on Michaels comment #39 https://gerrit.libreoffice.org/#/c/50908

(In reply to Jan-Marek Glogowski from comment #43)
> Some patches based on Michaels comment #39
> https://gerrit.libreoffice.org/#/c/50908
Built master with the patches, and it's looking good, no crash anymore.

(In reply to Aron Budea from comment #44)
> (In reply to Jan-Marek Glogowski from comment #43)
> > Some patches based on Michaels comment #39
> > https://gerrit.libreoffice.org/#/c/50908
> Built master with the patches, and it's looking good, no crash anymore.

No crashes from the bug, or just the assertion?

Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c15ea73f960bbd3d2a4b0c43b467ac62eeba3505

tdf#115420 WIN clean up WinSalFrames DC handling

It will be available in 6.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=06d09fdf75edaa94767013e23ddb677812bf2be6&h=libreoffice-6-0

tdf#115420 WIN clean up WinSalFrames DC handling

It will be available in 6.0.3.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Jan-Marek Glogowski,

After the fix for this, I'm getting the following build failure with a 'make check' under windows:
https://pastebin.com/iMJq68V3 after your fix for this bug,

Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8939cb9456ee76a848cc8089747f280751092cf8

tdf#115420 fix DC usecount and drop wrong asserts

It will be available in 6.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8e870ea9b828166b89a5c3f6c4f060bde6082f26&h=libreoffice-6-0

tdf#115420 fix DC usecount and drop wrong asserts

It will be available in 6.0.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-6-0-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=17185b48422f4d766e52bbbe38932901969c4f93&h=libreoffice-6-0-3

tdf#115420 fix DC usecount and drop wrong asserts

It will be available in 6.0.3.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

*** Bug 118646 has been marked as a duplicate of this bug. ***