Description: Open Tools /Extension Manager then Check for Updates. Extension Update window don't find any update available. Closing this windows crash LibreOffice I remove my old user profile, no more extension added. Languages and helps for en-GB, en-US, es, fr, it, pt and pt-BR crashreport.libreoffice.org/stats/crash_details/e164e43c-2e96-488b-ab3a-f74b336e52c9 or crashreport.libreoffice.org/stats/crash_details/965228ad-87b1-461a-9a4b-84100166e91e Steps to Reproduce: 1.Open Tools /Extension Manager 2.Check for Updates 3.Closing this windows crash LibreOffice Actual Results: Crash of LibreOffice. Disabling OpenGL solve this problem. Expected Results: Closing this window as expected Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Version: 6.0.0.3 (x64) Build ID: 64a0f66915f38c6217de274f0aa8e15618924765 Threads CPU : 8; OS : Windows 6.1; UI Render : GL; Locale : fr-FR (fr_FR); Calc: CL Languages and helps for en-GB, en-US, es, fr, it, pt and pt-BR User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
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. ***
(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.
(In reply to Mike Kaganski from comment #33) > 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. ... and one of those constructed OpenGLFlushIdle objects indeed was the one for the WinSalFrame in question.
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. ***