Irrespective of document type or application module used, LibreOffice master : Version: 5.3.0.0.alpha0+ Build ID: e735ba57da04dc77ff1bfe6c3d48dacae42b0f87 Threads CPU : 2; Version de l'OS :Mac OS X 10.11.5; UI Render : par défaut; Locale : fr-FR (fr.UTF-8); Calc: group and displays the Document Recovery window, even though there might be no document needing recovery.
The pain with this is that the user is obliged to kill the app via ForceKill in order to remove the Recovery Dialog, and close the application.
lldb output : Process 22807 launched: '/Applications/LibreOfficeDev.app/Contents/MacOS/soffice' (x86_64) warn:configmgr:22807:1:configmgr/source/propertynode.cxx:62: non-nillable property without value warn:configmgr:22807:1:configmgr/source/propertynode.cxx:62: non-nillable property without value warn:sal.osl.pipe:22807:1:sal/osl/unx/pipe.cxx:395: shutdown() failed: Socket is not connected warn:sal.osl.pipe:22807:3:sal/osl/unx/pipe.cxx:436: accept() failed: Software caused connection abort Assertion failed: (ImplGetSVData()->mpDefInst->CheckYieldMutex() && "SolarMutex not locked"), function ImplDbgTestSolarMutex, file /Volumes/BUILDHD/Shared/LO/core/vcl/source/app/dbggui.cxx, line 47. Process 22807 stopped * thread #1: tid = 0xb37429, 0x00007fff9b52cf06 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT frame #0: 0x00007fff9b52cf06 libsystem_kernel.dylib`__pthread_kill + 10 libsystem_kernel.dylib`__pthread_kill: -> 0x7fff9b52cf06 <+10>: jae 0x7fff9b52cf10 ; <+20> 0x7fff9b52cf08 <+12>: movq %rax, %rdi 0x7fff9b52cf0b <+15>: jmp 0x7fff9b5277cd ; cerror_nocancel 0x7fff9b52cf10 <+20>: retq
Created attachment 126355 [details] backtrace
Hi Alex, I recall this behavior but think it is resolved in latest master builds. Your self-compile does not have a date. Is this the latest version? Did you try with latest master from http://dev-builds.libreoffice.org/daily/master/MacOSX-x86_64@49-TDF/ ?
(In reply to steve -_- from comment #4) > Hi Alex, I recall this behavior but think it is resolved in latest master > builds. Your self-compile does not have a date. Is this the latest version? > Did you try with latest master from > http://dev-builds.libreoffice.org/daily/master/MacOSX-x86_64@49-TDF/ ? Hi Steve, Tested against my fresh master build of yesterday (22/07) morning. Note that my build is a debug build, and it appears from the trace that in dbggui.cxx the mutex guard isn't released/acquired.
I know that Caolan fixed a similar bug in master the other day, but this one still appears to be triggered in the debug build (which it didn't previously).
Is there any timing related aspect to this. e.g. does this only happen if you open and close LibreOffice quickly. If so, does it make a difference if you open libreoffice, wait 2 mins, and then close libreoffice ?
hmm commit 4f27ff917237be96eec897d4af90a3379be904c6 Author: Tor Lillqvist <tml@iki.fi> Date: Mon Jul 29 18:24:23 2013 +0300 Avoid SolarMutex assertion in a dbgutil build when exiting Impress put in a SolarMutex in that ImpTimedRefDev dtor commit 9f0766917a4fb1bc8fe1786c3b46132dd63c1c66 Author: Armin Le Grand <Armin.Le.Grand@cib.de> Date: Fri Jul 1 14:40:00 2016 +0200 tdf#50613 add support to load charts asynchronously took it back out again
@C: AFAIR not by purpose - really hmmm...
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fedd856894f3c9ae5a6c4afb58c43922e3e7dbeb Resolves: tdf#101067 put SolarMutexGuard back in again It will be available in 5.3.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.
Amazing ! Thanks guys ! Alex