The Extension Manager dialog freezes after installing an extension on Mac for LibreOffice version 220.127.116.11. This issue only affects Mac. Windows and Linux are fine. This issue does NOT occur in version 18.104.22.168. 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 22.214.171.124 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
The Extension Manager dialog will freeze after installing the extension.
The Extension Manager dialog should not freeze after installing the extension.
User Profile Reset: Yes
This issue is also present in 126.96.36.199.
I just confirmed this does NOT happen in version 188.8.131.52.
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
-> 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 :
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
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]
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.
This seems to be fixed in 184.108.40.206 and 220.127.116.11. 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.