Bug 115420 - Crash using "Close" button for Extension Manager -> Check for Updates dialog
Summary: Crash using "Close" button for Extension Manager -> Check for Updates dialog
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.0.0.3 release
Hardware: x86-64 (AMD64) Windows (All)
: highest critical
Assignee: Not Assigned
URL:
Whiteboard: target:6.1.0 target:6.0.3
Keywords: bibisected, bisected, haveBacktrace
: 115628 115764 115975 116115 (view as bug list)
Depends on:
Blocks: VCL-OpenGL
  Show dependency treegraph
 
Reported: 2018-02-03 09:30 UTC by JdTissot
Modified: 2018-07-11 13:13 UTC (History)
13 users (show)

See Also:
Crash report or crash signature: ["google_breakpad::ExceptionHandler::HandlePureVirtualCall()","OpenGLSalGraphicsImpl::doFlush()"]


Attachments
Crash dump (159.59 KB, application/octet-stream)
2018-02-03 09:32 UTC, JdTissot
Details
Open GL device log (313 bytes, text/plain)
2018-02-03 09:41 UTC, JdTissot
Details
Last open GL log with last driver from NVidia (314 bytes, text/plain)
2018-02-03 09:55 UTC, JdTissot
Details
OpenGL Device log file (314 bytes, text/plain)
2018-02-03 16:10 UTC, JdTissot
Details
LO 6.0.1.1 OpenGL device log Intel HD Graphics 620 on Windows 10 Home ver 1709 64-bit (316 bytes, text/plain)
2018-02-11 20:31 UTC, V Stuart Foote
Details
windbg-64 StackTrace of Crashing LO6.0.1.1 on close of Extension Manager check for update (11.88 KB, text/plain)
2018-02-19 21:44 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description JdTissot 2018-02-03 09:30:22 UTC
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
Comment 1 JdTissot 2018-02-03 09:32:23 UTC
Created attachment 139546 [details]
Crash dump
Comment 2 Julien Nabet 2018-02-03 09:37:12 UTC
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?
Comment 3 JdTissot 2018-02-03 09:41:51 UTC
Created attachment 139547 [details]
Open GL device log
Comment 4 JdTissot 2018-02-03 09:43:14 UTC
Disabling Open GL solve this problem
Comment 5 JdTissot 2018-02-03 09:55:21 UTC
Created attachment 139548 [details]
Last open GL log with last driver from NVidia

Updating NVidia driver doesn't solve this problem.
Comment 6 Julien Nabet 2018-02-03 15:17:53 UTC
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.
Comment 7 JdTissot 2018-02-03 15:24:38 UTC
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
Comment 8 Julien Nabet 2018-02-03 15:51:49 UTC
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.
Comment 9 JdTissot 2018-02-03 16:10:53 UTC
Created attachment 139557 [details]
OpenGL Device log file
Comment 10 JdTissot 2018-02-03 16:12:03 UTC
I had to add Grammalecte-fr-v0.5.17 extension to verify update, LibreOffice crash again
Comment 11 Julien Nabet 2018-02-03 16:14:38 UTC
(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?
Comment 12 JdTissot 2018-02-03 16:15:35 UTC
With OpenGL enabled
Comment 13 Julien Nabet 2018-02-11 20:12:49 UTC
*** Bug 115628 has been marked as a duplicate of this bug. ***
Comment 14 V Stuart Foote 2018-02-11 20:31:00 UTC
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...
Comment 15 Julien Nabet 2018-02-19 20:42:28 UTC
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.
Comment 16 V Stuart Foote 2018-02-19 21:44:42 UTC
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
Comment 17 V Stuart Foote 2018-02-19 21:57:01 UTC
*** Bug 115764 has been marked as a duplicate of this bug. ***
Comment 18 jorortega 2018-02-20 01:32:57 UTC
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.
Comment 19 Xisco Faulí 2018-02-20 11:45:56 UTC
@Telesto, @V Stuart, any change it can be bisected?
Comment 20 V Stuart Foote 2018-02-20 20:54:02 UTC
@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?
Comment 21 Michael Meeks 2018-02-20 20:58:49 UTC
Oh - I was rather convinced by comment#18 =) Its great to see the trace there ! should make things much easier ... nice work.
Comment 22 V Stuart Foote 2018-02-20 21:28:53 UTC
(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
Comment 23 Aron Budea 2018-02-20 22:10:37 UTC
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
Comment 24 Julien Nabet 2018-02-20 22:14:28 UTC
(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.
Comment 25 Aron Budea 2018-02-20 22:17:16 UTC
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
Comment 26 Aron Budea 2018-02-20 22:20:44 UTC
(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.
Comment 27 Julien Nabet 2018-02-20 22:24:48 UTC
(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.
Comment 28 Aron Budea 2018-02-20 22:30:28 UTC
(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.
Comment 29 Michael Meeks 2018-02-21 08:33:21 UTC
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.
Comment 30 Jan-Marek Glogowski 2018-02-22 18:19:45 UTC
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.
Comment 31 Aron Budea 2018-02-23 17:54:14 UTC
I assume this can be added to VCL-OpenGL again.
Comment 32 V Stuart Foote 2018-02-23 19:02:33 UTC
*** Bug 115975 has been marked as a duplicate of this bug. ***
Comment 33 Mike Kaganski 2018-02-23 19:58:03 UTC Comment hidden (obsolete)
Comment 34 Mike Kaganski 2018-02-23 20:06:47 UTC Comment hidden (obsolete)
Comment 35 Mike Kaganski 2018-02-24 06:42:27 UTC
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).
Comment 36 Michael Meeks 2018-02-24 18:53:52 UTC
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.
Comment 37 Julien Nabet 2018-03-01 16:13:25 UTC
*** Bug 116115 has been marked as a duplicate of this bug. ***
Comment 38 Michael Meeks 2018-03-06 17:15:31 UTC
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.
Comment 39 Michael Meeks 2018-03-06 17:26:52 UTC
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.
Comment 40 Aron Budea 2018-03-07 05:33:53 UTC
(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.
Comment 41 Michael Meeks 2018-03-07 09:44:03 UTC
Can you get a trace for that assertion failure ? looks odd =) thanks !
Comment 42 Jan-Marek Glogowski 2018-03-07 13:00:35 UTC
(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
Comment 43 Jan-Marek Glogowski 2018-03-07 17:51:58 UTC
Some patches based on Michaels comment #39 https://gerrit.libreoffice.org/#/c/50908
Comment 44 Aron Budea 2018-03-07 23:56:42 UTC
(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.
Comment 45 Jan-Marek Glogowski 2018-03-08 08:58:33 UTC
(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?
Comment 46 Commit Notification 2018-03-08 14:15:12 UTC
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.
Comment 47 Commit Notification 2018-03-08 17:54:02 UTC
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.
Comment 48 Luke 2018-03-12 00:30:43 UTC
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,
Comment 49 Commit Notification 2018-03-19 12:32:26 UTC
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.
Comment 50 Commit Notification 2018-03-21 15:33:41 UTC
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.
Comment 51 Commit Notification 2018-03-21 21:04:47 UTC
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.
Comment 52 Xisco Faulí 2018-07-11 13:13:58 UTC
*** Bug 118646 has been marked as a duplicate of this bug. ***