Description: The Extension Manager dialog freezes after installing an extension on Mac for LibreOffice version 6.1.4.2. This issue only affects Mac. Windows and Linux are fine. This issue does NOT occur in version 6.0.7.3. After this bug freezes the Extension Manager dialog you have to quit LibreOffice--when you restart you find the extension has been installed correctly. I tested using the Code Highlighter Writer extension: https://extensions.libreoffice.org/extensions/code-highlighter, but affects all extension I tried. Steps to Reproduce: 1.On Mac, using version 6.1.4.2 open Writer 2.From the Extension Manager try to install an extension, for example "Code Highlighter" 3.Install for one user only 4.The dialog will freeze Actual Results: The Extension Manager dialog will freeze after installing the extension. Expected Results: The Extension Manager dialog should not freeze after installing the extension. Reproducible: Always User Profile Reset: Yes Additional Info:
This issue is also present in 6.2.0.2.
I just confirmed this does NOT happen in version 6.1.4.1.
Pretty certain that this is a DUP. Need to find it.
@Jeremy: can you let us know which version of macOS you are using ? Thanks.
@Jeremy: the general behaviour you describe is similar to that reported in bug 99784, however that was fixed for 6.0, so we will need more details : - how exactly are you installing the extension (your step 2)? - via drag and drop of the OXT file onto the LO dock icon ? - via the Extensions Manager UI, chossing an extension from Finder, and then clicking "Add" ?
@Jeremy : don't worry, I can reproduce this if I select the "install for single user" option in the Extensions Manager UI. I don't reproduce this if I install for all users. lldb indicates that the problem is here : Process 4410 resuming Process 4410 stopped * thread #24, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7ffeef3ff7d8) frame #0: 0x00007fff2fe07fca CoreGraphics`argb32_mark + 146 CoreGraphics`argb32_mark: -> 0x7fff2fe07fca <+146>: movq %rsi, -0x10d8(%rbp) 0x7fff2fe07fd1 <+153>: movq 0x88(%r15), %r14 0x7fff2fe07fd8 <+160>: movl %edx, %eax 0x7fff2fe07fda <+162>: andl $0xff0000, %eax ; imm = 0xFF0000 Target 0: (soffice) stopped.
@Jan-Marek, Michael : thought you might be interested in this one. It seems similar to bug 99784 which was fixed for 6.0. However, the option of only installing for a single user seems to trigger the same behaviour.
FWIW reproduced on master : Version: 6.3.0.0.alpha0+ Build ID: 31c1995037a7ad408a5af6917288d8e3888a472d CPU threads: 4; OS: Mac OS X 10.14.2; UI render: default; VCL: osx; Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US Calc: threaded
Steps to reproduce : 1) Start LO 2) Menu Tools > Extension Manager 3) Click on "Add". Select an extension from the Finder. 4) Click on the "Only For Me" button. 5) Extension Manager UI either hangs on attempting installation, or after the extension has been installed - the Extension Manager UI window remains unresponsive and can not be closed and does not respond to mouse click interaction.
Created attachment 148391 [details] lldb backtrace I managed to obtain the enclosed backtrace from the hung LO process - whether or not it is relevant is another matter...
Trace (thanks Alex) looks rather like the other problem we have when building with a modern compiler for OSX. I would rather suspect that we are doing a ton of rendering - at high frequency - and that OSX is batching all of this up to be rendered later. Then - when it comes to render it - it tries to do clever scene analytics to partition the work (which makes sense) - but their apparently recursive algorithm blows up for large amounts of data and hangs. May be compounded by some producer/consumer mismatch I guess - such that one thread is queueing new things to render regularly while the other is fighting a loosing battle to partition / analyse that for GPU dispatch somewhere else. At least, that's my guess. Might be interesting to see what VCL rendering APIs are being called - and/or how much 'paint' stuff is actually going on - possibly a SAL_LOG=1 output for a dbgutil build would show that. Thanks !
This seems to be fixed in 6.1.5.2 and 6.2.0.3. Thanks!
seeing as the original report's problem seems to have gone away, lets close this
WORKSFORME as there is no commit if I am not mistaken.