We can't install an extension on OS X by double click on oxt file.
*** Bug 95573 has been marked as a duplicate of this bug. ***
Confirmed → NEW Version: 5.2.0.0.alpha1+ Build ID: b871a97d35a4160b7403c07bfac10aaa744fbbfd CPU Threads: 4; OS Version: Mac OS X 10.11.4; UI Render: default; TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2016-05-11_01:01:27 Locale: de-DE (de.UTF-8) Reproduce steps 1. download any extension from the extension website e.g. " Copy only visible cells" from http://extensions.libreoffice.org/extension-center/copy-only-visible-cells 2. double click downloaded .oxt file Currently Libreoffice extension manager opens and installation starts but gets stuck after a few seconds Expected Installation should work just as it does when clicking "Add..." in the extension manager.
I know the Add button work, but the bug is for the double click installation.
The bug with "Add..." button is already fix (Bug 95573), but not for the double click.
Created attachment 125143 [details] Screenshot of malloc trace using Instruments.app FWIW, I am enclosing an Instruments.app trace of malloc behaviour on LO-dev master. Note the profile is relatively smooth at the beginning, when LO is launched. The memory heap increases continuously when I drag and drop an extension onto the LO app icon in the dock and the install extension dialog appears (at which point the app stops responding).
Created attachment 125144 [details] Call tree after dropping extension file onto LO app icon Enclosed is a compressed file with the call tree obtained via the Instruments.app with LO master on OSX. This represents all calls made up to the point where the extensions UI is displayed after having dropped an OXT file onto the LO app icon in the dock.
Created attachment 125145 [details] Time profile of user calls This file is a compressed text file of a time profile of user calls when LO-dev master is already running and an extension (OXT) file is dropped onto the app icon in the dock.
I am having the same exact problem. LO Version: 5.1.4.2 Mac 10.11.5 I followed the procedure of going to the Extension Manager and choosing an extension from the open file dialog. The same exact thing happens where it starts for a few seconds but then hangs. If I leave it running, I get a memory error from my Mac stating that my system is about to run out of memory. This happens regardless of what extension I try to install.
Hi, I'm just a whiner with nothing new to provide. But *please*, can this be assigned and fixed? I've been waiting and hoping for months now. I promise a $20USD donation to document foundation upon this bug being fixed and released. Ricky Charlet
I have this very same problem in OSX 10.11.6 with LibreOffice 5.1.4.2, and the Add button on the extension manager do NOT work either, so it seems I cannot install extensions at all.
This problem is still there also in LO 5.2.0.4 (on OSX 10.11.6). As well as the update of existing extensions.
This is a blocker for OSX releases. Until this is solved no LO releases should go out. The extensions system is a basic subsystem of LibreOffice, it must work or there should be a warning in the install/release notes and download page that this major feature is not working on OSX at all.
> This is a blocker for OSX releases. We don't have blockers I'm afraid - time-based releases don't allow them. > Until this is solved no LO releases should go out. Coercing others into solving your favourite problems is not going to work. So - lets think of more positive ways. The ultimate reason why this bug is not fixed is: I don't have a Mac, I don't have access to a Mac, I'm not going to buy a Mac on my own $, and I don't have much time - even if I could solve the above. If someone can give me remote access to a Mac with a pre-build LibreOffice with debugging symbols, a console, and so on - then it would be easy enough to make progress here I think. Can you provide that ? (NB. if Apple were not quite so hyper-lame about forbidding virtualisation - then we could all debug and fix Mac problems, as we can do for Windows & Linux). Alex - the time profile looks interesting, but nothing jumps out of it. The bug is almost certainly quite trivial - an Idle handler or Timeout is being created inside another Idle handler or Timeout - and is starving the UI from being re-rendered. We just need to catch that and re-prioritise.
(In reply to Michael Meeks from comment #14) Hi Michael, > Alex - the time profile looks interesting, but nothing jumps out of it. The > bug is almost certainly quite trivial - an Idle handler or Timeout is being > created inside another Idle handler or Timeout - and is starving the UI from > being re-rendered. We just need to catch that and re-prioritise. Is there any tool that you know of and which does not involve jumping through hoops to get it to work on OSX that I might be able to use to bring this along further ?
Created attachment 127511 [details] Apple trace FWIW, I am enclosing an Apple trace against my master 530 build which is produced when I force kill a hung LO process after dropping an OXT file onto the LO icon in the OSX Dock - don't know whether that helps much
I'm on Mac. If you said me what you need (log, test…) to fix the problem, I can made it for you. If you need I have Teamviewer and I can let you made some test by yourself.
Hi shunesberg - it would be awesome if you could do some of this remote debugging. Getting a build of master with --enable-dbgutil configured into it (from clean) would be really helpful; and then doing: export SAL_LOG=+INFO.vcl.schedule+WARN.vcl.schedule into the environment, and running and stashing the output of that while making it hang. Clearly it's a priority problem. If you could get that - I think we'd make some progress. Failing that - putting some breakpoints into vcl/source/app/scheduler.cxx to see what new Idle/Timeout task is being added, at what priority in order to make these bad things happen - would be great to find out =) Thanks !
@Michael : I added a scheduler trace containing the output from the terminal with the SAL command you indicated. I don't think that is going to help much as it doesn't seem to identify which code path is responsible. This is just a short sample of the output, as I managed to bring my Mac mini to its knees by letting it run for 2 minutes or so. The same messages just seem to get respawned constantly.
Created attachment 127543 [details] SAL schedule export
I ran that SAL export against my master debug enabled build
@Michael Meeks: What would I do to run with "--enable-dbgutil". Where I type "export SAL_LOG=+INFO.vcl.schedule+WARN.vcl.schedule" I'm not a hacker, I don't know what to do. And the English it's not my native language.
When I run in a terminal with: /Applications/LibreOfficeDev.app/Contents/MacOS/soffice (the option "--enable-dbgutil" is not recognized) But When I try to a drop of an oxt file on LibreOffice, the result is: warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-af/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-an/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-ar/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-be/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-bg/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-bn/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-br/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-bs/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-ca/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-cs/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-da/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-de/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-el/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-et/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-gd/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-gl/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-gu/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-he/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-hi/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-hr/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-hu/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-is/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-it/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-kmr-Latn/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-lo/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-lt/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-lv/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-ne/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-nl/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-no/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-oc/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-pl/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-pt-BR/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-pt-PT/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-ro/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-ru/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-si/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-sk/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-sl/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-sr/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-sv/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-sw/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-te/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-th/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-uk/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-vi/META-INF/manifest.xml> warn:desktop.deployment:15413:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-zu/META-INF/manifest.xml>
I try an other test with the opening of a oxt by double click: warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-af/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-an/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-ar/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-be/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-bg/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-bn/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-br/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-bs/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-ca/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-cs/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-da/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-de/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-el/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-et/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-gd/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-gl/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-gu/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-he/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-hi/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-hr/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-hu/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-is/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-it/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-kmr-Latn/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-lo/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-lt/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-lv/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-ne/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-nl/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-no/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-oc/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-pl/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-pt-BR/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-pt-PT/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-ro/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-ru/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-si/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-sk/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-sl/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-sr/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-sv/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-sw/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-te/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-th/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-uk/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-vi/META-INF/manifest.xml> warn:desktop.deployment:15462:1:desktop/source/deployment/registry/package/dp_package.cxx:1430: cannot create UCB Content for <file:///Applications/LibreOfficeDev.app/Contents/Resources/../Resources/extensions/dict-zu/META-INF/manifest.xml>
Hmm; --enable-dbgutil is what you'd pass to configure before compiling the software ;-) so - not a run-time parameter - it builds a -much- larger build with symbols, and logging and so on inside itself. Alex - thanks for the trace; if you are churning debug that fast from that place - then it is indeed an idle handling issue; it is strange that we get: info:vcl.schedule:1182:1:vcl/source/app/scheduler.cxx:242: Have active idle vcl::Window maPaintIdle so frequently - and yet (apparently) no UI update. I guess I need access to a Mac to poke at this one.
I now have access to a remote Mac (thanks to Cloph), but - unfortunately - a truck-load of extraordinarily time-consuming business problems to solve - which can't wait, so getting a Mac setup, learning XCode, debugging etc. is not something I can get to in the next week or two I think; sorry ...
*** Bug 101918 has been marked as a duplicate of this bug. ***
(In reply to Michael Meeks from comment #26) @Michael : I have a VM allocation trace profile produced with Apple XCode Instruments. The trace itself is 1.36Gb of data, it can be opened and analysed in the Instruments.app provided with the XCode developer tools. I have compressed this trace to a zip file, but even then, it weighs in at 300Mb. I am providing a link to this on my Dropbox account for anyone that is interested, has access to the XCode tools, and likes to poke around ;-) https://dl.dropboxusercontent.com/u/107086405/ExtensionAdd.trace.zip FWIW, the profile is of interest with regard to this bug from approximately 1.19 minutes from the start. What precedes that is LO starting up, and the call up and display of the StartCenter. The OpenGL code called just before malloc goes wild is the graphical UI action of dragging and dropping an OXT file via the UI onto the StartCenter window (this is actually really slow to do physically on a debug build but I got there in the end). The problems, at least with the mallocs, and the stalling of the application, appear to start after that, so the calls that you are probably interested in will be from 1.19 min onwards.
Hi Alex; wow - sounds awesome. Is there any chance of some screencast / video of what goes on / wrong here ? - also I'm surprised to hear of OpenGL being used (by us) on the Mac - I believe it is off by default there - but of course, it's prolly used by the backend. Quite possibly we have some invalidate loop - where we invalidate during painting - might be worth looking for that - with a breakpoint in eg. void Window::ImplInvalidate( const vcl::Region* pRegion, InvalidateFlags nFlags ) that guy (vcl/source/window/paint.cxx). Thanks !
(In reply to Michael Meeks from comment #29) I'll see what I can do. I'm not very "au fait" with screen recording software on Mac, but I can try and set a breakpoint where you indicated and see what happens.
on board quicktime allows screenrecordings
Screenshot on MacOS is not difficult: http://www.imore.com/screenshot-mac For recording screen: Open "QuickTime Player" in the "File" menu you can see "New Screen Recording". For more details, see here: https://support.apple.com/kb/ph5882
Bug confirmed. Any extension, even the more simplest one. Still present on LO 5.2.2.2, under MacOS 10.10 Is there a way to install manually any extension, such as unzip and put on the right ~/Library/ folder ?
BTW, this bug is major, not critical. Windows bug #99763 IS critical, not major. The difference ? You can use LO without any extension, according to this #99784, but you cannot use LO Draw without crash with #99763.
(In reply to Gaétan RYCKEBOER from comment #34) > > Is there a way to install manually any extension, such as unzip and put on > the right ~/Library/ folder ? From a terminal : Example /Applications/LibreOffice.app/Contents/MacOS/unopkg add /Users/alex/Downloads/HelpAuthoring-3.1.3.oxt
OK, so I created a video screen capture of the malloc trace using the Apple XCode Instruments app. As the video is larger than the allowed size for upload to BZ, I have uploaded it to my public Dropbox space, and will provide a link below : https://dl.dropboxusercontent.com/u/107086405/screencast_Apple_Instruments_malloc_trace.mov
Hi Alex; I watched the video - it shows the memory increasing - which in itself is interesting - but unfortunately doesn't give us a good idea of where those memory allocations actually come from =) Can we not use the tool to explore what the stack trace of those allocations is ? ie. where in the 8 millions lines does it come from (it could be in the extension too FWIW ;-). Without that this is very much a "something leaks" type report. Thanks !
(In reply to Michael Meeks from comment #38) > Hi Alex; I watched the video - it shows the memory increasing - which in > itself is interesting - but unfortunately doesn't give us a good idea of > where those memory allocations actually come from =) Can we not use the tool > to explore what the stack trace of those allocations is ? ie. where in the 8 > millions lines does it come from (it could be in the extension too FWIW ;-). > Without that this is very much a "something leaks" type report. > > Thanks ! Hi Michael, That is precisely what the Instruments.trace file is for. It contains a hierarchical tree list of all calls made, but as far as I can tell, you can only exploit this file via the Instruments.app. In reality, the trace file is a compressed folder containing various objects that Instruments.app knows how to read and display and allows the user to pinpoint the calls being made at any given point along the profile. If the trace is coupled to symbols and source code, which it can be, and which I haven't undertaken, one can apparently examine the code path in even greater detail, but all of that is beyond me, I'm afraid.
It seems to me that the problem isn't just a LO regression, but also affected by changes introduced with MacOS El Capitan. - Mavericks 10.9.5 & Yosemite 10.10.5: the problem described starts between LO 5.0.6.3 (working) - 5.1.0.1 (failing), without high CPU usage. - MacOS Sierra 10.12: haven't found a working version yet.
Created attachment 128358 [details] Xcode Instruments Memory Allocation LO 5.0.6.3 on Sierra 10.12 Memory Allocation after double click on the extension.
(In reply to Alex Thurgood from comment #19) > @Michael : I added a scheduler trace containing the output from the terminal > with the SAL command you indicated. I don't think that is going to help much > as it doesn't seem to identify which code path is responsible. This is just > a short sample of the output, as I managed to bring my Mac mini to its knees > by letting it run for 2 minutes or so. The same messages just seem to get > respawned constantly. I have a longer more - informative - SAL schedule trace output. Reproduction steps: 1. I downloaded " Copy only visible cells" from http://extensions.libreoffice.org/extension-center/copy-only-visible-cells 2. Start LO and wait for the start centre to appear 3. double click downloaded .oxt file The follow output is repeating itself over and over: info:vcl.schedule:821:6:vcl/source/app/svapp.cxx:509: DoYield with active idles returns: timeout info:vcl.schedule:821:6:vcl/source/app/scheduler.cxx:174: Invoke task unknown info:vcl.schedule:821:6:vcl/source/app/svapp.cxx:525: Leave ImplYield info:vcl.schedule:821:6:vcl/source/app/svapp.cxx:478: Enter ImplYield: wait: one event: 0 info:vcl.schedule:821:6:vcl/source/app/scheduler.cxx:206: Calculating minimum timeout: info:vcl.schedule:821:6:vcl/source/app/scheduler.cxx:237: Have active timer Timer to destroy drawinglayer reference deviceupdate min period from 60000 to 60000 info:vcl.schedule:821:6:vcl/source/app/scheduler.cxx:237: Have active timer Auto save timerupdate min period from 60000 to 60000 info:vcl.schedule:821:6:vcl/source/app/scheduler.cxx:242: Have active idle unknown info:vcl.schedule:821:6:vcl/source/app/scheduler.cxx:237: Have active timer unknownupdate min period from 60000 to 63 info:vcl.schedule:821:6:vcl/source/app/scheduler.cxx:264: Calculated minimum timeout as 63 and has active idles Version: 5.3.0.0.alpha0+ Build ID: a9afa89e953f0f32acf26b143717e7d067cbc75a CPU Threads: 4; OS Version: Mac OS X 10.12.1; UI Render: default; TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2016-10-13_05:13:57 Locale: nl-NL (nl_NL.UTF-8); Calc: group
Created attachment 128483 [details] SAL_LOG=+INFO.vcl.schedule+WARN.vcl.schedule
Hi Telesto - thanks for doing that; it is interesting that (absent any time details - which is a shame) by line numbers we have a log of 380k lines - and we're getting PaintIdle handling all the way through, and towards teh end: 382002 info:vcl.schedule:821:6:vcl/source/app/scheduler.cxx:174: Invoke task vcl::Window maPaintIdle So - in theory we're continuing to process idle events, and render things too. I'm rather confused - people use the word 'hang' and so on - can someone make a video of just the app failing ? what happens ? - sorry the bug is by now unbelievably long and totally un-readable in linear time. Thanks for debugging !
*** Bug 103699 has been marked as a duplicate of this bug. ***
@Michael Meeks. As requested: http://www21.zippyshare.com/v/lItxDICB/file.htm Accidentally I also recorded bug 77444 (opening any document by double-click never opens the file. mouse movement required for the file to open)
The ZippyShare thing is a virus / phishing / malware infested nightmare - AFAICS =) the two times I went there I ended up with some fake virus junk =) I created and mailed you an account on our demo server instead. Thanks =)
(In reply to Michael Meeks from comment #48) > The ZippyShare thing is a virus / phishing / malware infested nightmare - > AFAICS =) the two times I went there I ended up with some fake virus junk =) > I created and mailed you an account on our demo server instead. Thanks =) Screenrecordering with corresponding terminal output (including time details) https://drive.google.com/open?id=0B7DezVIXHrQOT1lleWJxV2pDeG8
Thanks for the movie. So - I'm trying to understand the description here. There is talk of a crash/hang - and yet the UI appears to be rendered. The dialog appears to stop when it is at some low %age of "Adding copyvisicells.oxt" [Cancel]. Can someone who has a Mac report on whether the rest of the app is working - ie. is it possible to load files, interact with existing LibreOffice windows, etc. while extensions are being installed (on other platforms) and on Mac - and is it possible to close the window while this is installing ?
(In reply to Michael Meeks from comment #50) > Thanks for the movie. So - I'm trying to understand the description here. > There is talk of a crash/hang - and yet the UI appears to be rendered. The > dialog appears to stop when it is at some low %age of "Adding > copyvisicells.oxt" [Cancel]. > > Can someone who has a Mac report on whether the rest of the app is working - > ie. is it possible to load files, interact with existing LibreOffice > windows, etc. while extensions are being installed (on other platforms) and > on Mac - and is it possible to close the window while this is installing ? On a Mac none of the windows respond to any interactions, including closing.
(In reply to Michael Meeks from comment #50) > Can someone who has a Mac report on whether the rest of the app is working - > ie. is it possible to load files, interact with existing LibreOffice > windows, etc. while extensions are being installed (on other platforms) and > on Mac - and is it possible to close the window while this is installing ? Hi Michael, No, the remainder of the app is to all intents and purposes unresponsive. Only a forced kill allows the user to shut all app windows. None of the toolbars react to clicks, whether in the unopkg gui or any other LO open windows, even the main application menu at the top of the screen is unresponsive.
Soo - looking at the code quickly which is in: desktop/source/deployment/gui/dp_gui_extensioncmdqueue.cxx It -looks- strongly as if this is some threaded use of VCL that is assuming that things are thread-safe that are not: void ProgressCmdEnv::progressSection( const OUString &rText, const uno::Reference< task::XAbortChannel > &xAbortChannel ) { m_xAbortChannel = xAbortChannel; m_nCurrentProgress = 0; if ( m_pDialogHelper ) { m_pDialogHelper->updateProgress( rText, xAbortChannel ); m_pDialogHelper->updateProgress( 5 ); } } Which does all manner of dodgy stuff like: DialogHelper::PostUserEvent( LINK( this, UpdateRequiredDialog, startProgress ), reinterpret_cast<void*>(bStart) ); which ultimately does: m_nEventID = Application::PostUserEvent( rLink, pCaller, true/*bReferenceLink*/ ) Which does some somewhat 'optimistic' code around in Application::PostUserEvent - which may well deadlock; it requires the SolarMutex for this case. Looks like another instance of people assuming that the vcl main-loop and event posting is thread-safe. Still - there are so few events, and so little going on this is unlikely to be the cause of the issue. I imagine that PostUserEvent is (somehow) not working nicely on Mac when called from a different thread in this case - but impossible to debug without a mac.
Created attachment 128577 [details] LLDB Backtrace
Created attachment 128613 [details] LLDB Backtrace I did try to step somewhat through opening process of an OXT, but I haven't really a clue what i'm searching for. Or what is relevant or not (novice) In thread 11 strtmpl.cxx doens't seem to work right (I guess). And maybe there is also a problem in Thread 1 with the Font Registry, because of a Libsystem malloc The log is quite long. For a general impression I would advice to search for: 'bt' (Match Whole Word Only) and 'unwind'
Backtrace looks normal enough - it looks like the thread that does the install is getting on with its business - not blocking, and the main UI thread is in the process of doing / pushing some deferred rendering events; so - nothing too surprising there. Perhaps it is worth waiting much longer to take a trace - when it has truly hung =)
Created attachment 128615 [details] LLDB Backtrace when stuck A retry. I did a backtrace after OXT adding stuck and a few steps forward. I also 'unwinded' thread 1, 6, and 10 (search for unwind)
Great trace Telesto, and nice to have in text too - no need to have the 's' stepping after the nice symbols backtrace though: frame #2: 0x00007fff8d6eb6ad libsystem_pthread.dylib`_pthread_mutex_lock_slow + 285 frame #3: 0x00007fff783f95de CoreFoundation`CFRunLoopPerformBlock + 670 frame #4: 0x00007fff76295053 AppKit`-[NSEvent _postAtStart:] + 191 frame #5: 0x0000000114e09c4d libvcllo.dylib`ImplSalStartTimer(nMS=41) + 701 at saltimer.cxx:84 frame #6: 0x0000000114e09f39 libvcllo.dylib`AquaSalTimer::Start(this=0x0000600000003820, nMS=41) + 25 at saltimer.cxx:126 if( pEvent ) [NSApp postEvent: pEvent atStart: YES]; deadlocks against: frame #10: 0x00007fff779a8c26 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 71 frame #11: 0x00007fff76092b79 AppKit`_DPSNextEvent + 1093 frame #12: 0x00007fff767a81c3 AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1637 frame #13: 0x0000000114e02ef6 libvcllo.dylib`AquaSalInstance::DoYield(this=0x00006080000be8a0, bWait=false, bHandleAllCurrentEvents=false, nReleased=0) + 998 at salinst.cxx:628 frame #14: 0x0000000114c928f0 libvcllo.dylib`ImplYield(i_bWait=false, i_bAllEvents=false, nReleased=0) + 1744 at svapp.cxx:505 Which is somewhat amazing ... Of course the gymnastics going on here to implement the sal timer callback API is pretty horrible, although since timers are protected by the solar mutex - perhaps posting an event to the main thread in order to set a timer event does make some sense (?) The: if( pSalData->mpFirstInstance->isNSAppThread() ) ... do the real stuff ... } else { ... post this event ... } It does seem extraordinary that ::Yield() when called by two separate threads on the Mac hangs this way. Norbert - any ideas ? =)
Within the backtrace I noticed the following errors: - “cannot write pidfile " - "cannot open pidfile " - @"AppKit cannot convert carbon event class '%.4s' to CGEventRef." - @"AppKit cannot convert carbon mouse event of kind '%ld' to CGEventRef." - @"AppKit cannot convert carbon mouse events of button '%ld' to CGEventRef." - @"WARNING: nextEventMatchingMask should only be called from the Main Thread! This will throw an exception in the future." - THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__
May be a duplicate of the bug you just fixed Noel =) at least the root bug ...
Created attachment 129449 [details] BUILDLOG; LLDB Backtrace and SAL_LOG The main issue still persists, but most errors and warnings found in the previous backtrace are gone. However: CoreFoundation`CFRunLoopAddTimer is still complaining about: __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__ Main issue seems to be frame 13 libsofficeapp.dylib`desktop::Desktop::Main: desktop::Desktop::HandleBootstrapErrors at app.cxx:836 desktop::(anonymous namespace)::MakeStartupConfigAccessErrorMessage at app.cxx:399 desktop::(anonymous namespace)::FatalError at app.cxx:432 I used: Version: 5.4.0.0.alpha0+ Build ID: a564821eb9e991774195120e6965b2a8b1419dc5 CPU Threads: 4; OS Version: Mac OS X 10.12.2; UI Render: default; Locale: en-US (en_US.UTF-8); Calc: group
This could be a duplicate of: bug#100337 - can you test a build with that fix included ?
Nope, adding an extension on OS X by double click isn't working with: Version: 5.4.0.0.alpha0+ Build ID: b52167df08511239c3d08904a3d12a3c92141f38 CPU Threads: 4; OS Version: Mac OS X 10.12.1; UI Render: default; TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2016-12-09_23:41:33 Locale: nl-NL (nl_NL.UTF-8); Calc: group Adding with the the extension manager does work (mostly), but everything is a far to slow. Just opening the extension manager dialog on a 'cold start' takes around 12 seconds. The adding proces is also way to slow using 100% CPU (1,4 GHz Intel Core i5) However, the dialogs in between respond well.
*** Bug 104806 has been marked as a duplicate of this bug. ***
Created attachment 130168 [details] LLDB Backtrace, Build Log, Instruments Time Profile Issue still persists. Updated backtrace Version: 5.4.0.0.alpha0+ Build ID: 2d54ffbf18d461c846535d539d704d45aff059b1 CPU Threads: 4; OS Version: Mac OS X 10.12.2; UI Render: default; Locale: en-US (en_US.UTF-8); Calc: group The extension adding process seems to be Thread 9. Row 7778 (and further) of the Time Profile results.
Created attachment 130345 [details] LLDB Backtrace, Build Log, Instruments Time Profile, Instruments Allocations Making progress, but still not working: Version: 5.4.0.0.alpha0+ Build ID: 88f561204d7cee25633df8117cc8d7e1ebd8e9ad CPU Threads: 4; OS Version: Mac OS X 10.12.2; UI Render: default; Locale: en-US (en_US.UTF-8); Calc: group Note: LLDB backtrace, Instruments Time Profile and Instruments Allocations are done in separate runs
Is there anything I could do? Is there a safe way for allowing someone to remote debug on my iMac computer? I have the latest iMac (Retina 4K, 21.5-inch, Late 2015, Intel Iris Pro Graphics 6200 1536 MB, 8 GB 1867 MHz DDR3, 3.1 GHz Intel Core i5) with Mac OS X Sierra with all system updates and patches installed (Mac OS X 10.12.2). I am also familiar with programming and debugging a bit and know how to use XCode or NetBeans. I would really like to help out.
TDF bought me a Mac to debug this on; I've even got soffice.bin in the debugger, and the extension downloaded ;-) but - waiting for some spare time to get to this.
@jazzjohannes if you come hang out on the irc channel we could help you get libreoffice building on your machine. Be warned that it is somewhat of an arduous process. Then you'd need to run it under a debugger and explore up and down the stack. Somewhere we are taking locks in the "wrong" order.
This issue is a serious problem for all of us who depend on extensions - e.g. academics who need to install the plug-in for Zotero, Endnote or another reference management software. We'd appreciate if a solution could be found - after all, this bug hasn't been resolved since May last year! Thanks a lot
The same for French users. The only way to get a real spell/grammar checker is with Grammalecte extension.
Created attachment 130464 [details] LLDB Backtrace Two backtraces with a different perspective. BT between adding an extension and license agreement, done with: Done with build +/- 12 Jan 2017 Version: 5.4.0.0.alpha0+ Build ID: 88f561204d7cee25633df8117cc8d7e1ebd8e9ad CPU Threads: 4; OS Version: Mac OS X 10.12.2; UI Render: default; Locale: en-US (en_US.UTF-8); Calc: group BT while opening Extension Manager Done with build +/- 4 Jan 2017 Version: 5.4.0.0.alpha0+ Build ID: 88f561204d7cee25633df8117cc8d7e1ebd8e9ad CPU Threads: 4; OS Version: Mac OS X 10.12.2; UI Render: default; Locale: en-US (en_US.UTF-8); Calc: group
Created attachment 130525 [details] LLDB Backtrace 1. BT between adding an extension and license agreement. Still some delay remaining, but making quite some progress 2. BT after double clicking OXT extension in finder. 3. A few off-topic backtraces Version: 5.4.0.0.alpha0+ Build ID: 562edf0f09ba4e82fb9186aa75ee88fd7f68d18f CPU Threads: 4; OS Version: Mac OS X 10.12.1; UI Render: default; Locale: nl-NL (nl_NL.UTF-8); Calc: group
Created attachment 130526 [details] LLDB Backtrace 1. BT between adding an extension and license agreement. Still some delay remaining, but making quite some progress 2. BT after double clicking OXT extension in finder. 3. A few off-topic backtraces Version: 5.4.0.0.alpha0+ Build ID: 562edf0f09ba4e82fb9186aa75ee88fd7f68d18f CPU Threads: 4; OS Version: Mac OS X 10.12.1; UI Render: default; Locale: nl-NL (nl_NL.UTF-8); Calc: group
Created attachment 130548 [details] SAL_LOG=+TIMESTAMP+INFO,+WARN Small addition to the BT from yesterday
Created attachment 130741 [details] LLDB Backtrace, BUILDLOG, SAL_LOG 1. BT between adding an extension and license agreement using the extension manager. Still a 10-15 sec delay remaining, but quite OK 2. BT after double clicking OXT extension in finder (still broken) Done with: Version: 5.4.0.0.alpha0+ Build ID: 562edf0f09ba4e82fb9186aa75ee88fd7f68d18f CPU Threads: 4; OS Version: Mac OS X 10.12.1; UI Render: default; Locale: nl-NL (nl_NL.UTF-8); Calc: group I build without using compiler plugins, it didn't work out of the box using the pre-canned (LODE) setup. --> Cannot find Clang headers to build compiler plugins, plugins disabled
*** Bug 105738 has been marked as a duplicate of this bug. ***
Created attachment 130979 [details] LLDB Backtrace, Build Log LLDB Backtraces 1. BT between dialog 'For whom do you want to install the extension' and the license agreement. Still a 8 second delay. Everything else is working fine (except the progress bar; bug 70289) 2. BT after double clicking OXT extension in finder (isn't working; still stuck) 3. A few off-topic backtraces (but probably related) Version: 5.4.0.0.alpha0+ Build ID: 6dce9c6757823b9e89863716ae70ff4e8ddd4e60 CPU Threads: 4; OS Version: Mac OS X 10.12.1; UI Render: default; Locale: nl-NL (nl_NL.UTF-8); Calc: group Did get a few build warnings: ld: warning: directory not found for option '-L/Users/demo/lode/dev/core/workdir/LinkTarget/StaticLibrary' ld: warning: directory not found for option '-L/Users/demo/lode/dev/core/workdir/LinkTarget/Library' ld: warning: directory not found for option '-L/Users/demo/lode/dev/core/instdir/LibreOfficeDev.app/Contents/Frameworks' ld: warning: directory not found for option '-L/Users/demo/lode/dev/core/instdir/LibreOfficeDev.app/Contents/Frameworks' ld: warning: directory not found for option '-L/Users/demo/lode/dev/core/workdir/LinkTarget/Library'
Created attachment 131039 [details] LLDB Backtrace, BUILDLOG I noticed that my last few backtraces didn't contain 'code-pointers'. Sorry for that. Again some backtraces: 1. BT between dialog 'For whom do you want to install the extension' and the license agreement. Still a 8 second delay. Everything else is working fine (except the progress bar; bug 70289) 2. BT after double clicking OXT extension in finder (isn't working; still stuck) 3. A few off-topic backtraces (but probably related) Version: 5.4.0.0.alpha0+ Build ID: b78c6d8efd9531243e62a388bffc3f071d9a56eb CPU Threads: 4; OS Version: Mac OS X 10.12.2; UI Render: default; Locale: en-US (en_US.UTF-8); Calc: group
Created attachment 131326 [details] BUILDLOG; LLDB Backtrace and SAL_LOG Updated backtraces: Version: 5.4.0.0.alpha0+ Build ID: 273823de644f2086377795d3afb51a39d30bfeaa CPU Threads: 4; OS Version: Mac OS X 10.12.2; UI Render: default; Locale: en-US (en_US.UTF-8); Calc: group The libi18nlangtag trace seems quite interesting: "LanguageTag::registerImpl: can't resolve system!" "LanguageTag::registerImpl: can't register for 0x"
Created attachment 131410 [details] LLDB backtrace Time Profile SalAquaPicker The response of pressing the add button in the extension manager is a bit slow. The button press is at frame 70 Version: 5.4.0.0.alpha0+ Build ID: 273823de644f2086377795d3afb51a39d30bfeaa CPU Threads: 4; OS Version: Mac OS X 10.12.4; UI Render: default; Locale: en-US (en_US.UTF-8); Calc: group
(In reply to Telesto from comment #81) > Created attachment 131410 [details] > LLDB backtrace Time Profile SalAquaPicker > > The response of pressing the add button in the extension manager is a bit > slow. The button press is at frame 70 > Version: 5.4.0.0.alpha0+ > Build ID: 273823de644f2086377795d3afb51a39d30bfeaa > CPU Threads: 4; OS Version: Mac OS X 10.12.4; UI Render: default; > Locale: en-US (en_US.UTF-8); Calc: group Bonjour! If I may interfere (my apologies by advance if this is completely off topic), I find that many GUI actions are slow on my mac and I have to keep quiet while editing using graphical displacement of objects in drawing or impress. I always keep a delay of ~0.5 seconds between clicking and dragging an object otherwise it often finishes off-screen. This might be a related problem or not, but I though I better let you know. Thank you all for the efforts on this critical problem (for mac users). Vincent.
Created attachment 131412 [details] Xcode Time Profile and some code peeks Xcode Instruments Time Profile between 'For whom do you want to install the extension' and the license agreement and a bunch of screenshots while peeking at the code (using Instruments) Version: 5.4.0.0.alpha0+ Build ID: 273823de644f2086377795d3afb51a39d30bfeaa CPU Threads: 4; OS Version: Mac OS X 10.12.4; UI Render: default; Locale: en-US (en_US.UTF-8); Calc: group
Created attachment 131442 [details] LLDB Backtrace, SAL_LOG It feels like LibO is running smoother. However there is still a noticeable delay's when opening menu's. I have added backtrace of dyld`dyldbootstrap when launching LibO. Version: 5.4.0.0.alpha0+ Build ID: a8538f0774bd0fabf6012d735d1e86b3ff1c291f CPU threads: 4; OS: Mac OS X 10.12.4; UI render: default; Locale: en-US (en_US.UTF-8); Calc: group
Created attachment 131462 [details] Time Profile License Agreement Dialog An the License agreement dialog keeps consuming CPU after showing up. It keeps hitting: SAL_IMPLEMENT_MAIN() { int ret = soffice_main(); Version: 5.4.0.0.alpha0+ Build ID: a8538f0774bd0fabf6012d735d1e86b3ff1c291f CPU threads: 4; OS: Mac OS X 10.12.4; UI render: default; Locale: en-US (en_US.UTF-8); Calc: group
Not sure if this the right place, nor do I know if it's useful, but used XCode Instruments to create Heap Allocation profile when launching LibO for the first time (after building it). https://drive.google.com/open?id=0B7DezVIXHrQOYW9FTlF4QlJuVHc (35 MB) I used a non-debug build (symbols only) Version: 5.4.0.0.alpha0+ Build ID: 4a332d54b80bbc502ccc98bf924a269e00c10070 CPU threads: 4; OS: Mac OS X 10.12.4; UI render: default; Locale: en-US (en_US.UTF-8); Calc: group
I did notice some progress, so again a Xcode Instruments Leak and Heap analysis. https://drive.google.com/open?id=0B7DezVIXHrQOUTVreXZJT3p2U3M (33 MB) I used a non-finalized re-build. The CppunitTest did - as always - fail (log attached). [I emptied dev/core/instdir, use ./setup --refresh to update and build LibO again with: make 2>&1 | tee build.log] As a consequence I can't give a correct build ID(I pulled git today around 13:00 UTC) Version: 5.4.0.0.alpha0+ Build ID: --- CPU threads: 4; OS: Mac OS X 10.12.4; UI render: default; Locale: en-US (en_US.UTF-8); Calc: group
Created attachment 131831 [details] LLDB Backtraces
Created attachment 131958 [details] LLDB Backtrace The responsiveness of LibO nearly back to normal. However, there are still some issues remaining. A few LLDB backtraces with a non-debug build (with symbols) Version: 5.4.0.0.alpha0+ Build ID: e7391ca132a9964dc9d870039a104abec044d357 CPU threads: 4; OS: Mac OS X 10.12.4; UI render: default; Locale: en-US (en_US.UTF-8); Calc: group
Telesto, I am not sure how relevant the responsiveness is to this bug at hand. For me when I try to install an extension (.oxt file) by double clicking that file I still run into a hang, LO is completely unusable has to be force quit, and fans go crazy. This has not improved since this bug was first reported back in Mai 2016.
@steve -_- You're right. My comment is irrelevant for this bug; sorry.
I'm experiencing a problem which ends up with a similar-sounding hang of Extension Manager with 100% CPU, but triggered differently. My problem is very similar to bug https://bugs.documentfoundation.org/show_bug.cgi?id=104806 "Updating (extensions) hangs application". That bug was marked as a duplicate of this, so I'll report my symptoms here. I'm using LibreOffice, v5.3.1.2 on Mac OS 10.11 El Capitan. To reproduce: * Run LibreOffice. Start Manager appears * Select menu item Tools... Extension Manager... Extension Manager appears. * Click button, "Check for Updates" Expected behaviour: * A UI appears immediately, indicating some check for updated extensions * Maybe updates appear * In any case, LibreOffice does not use 100% of CPU, does not hang, can be quit Observed behaviour: * The Extension Manager window goes into a "disabled" state. The red/yellow/green buttons in the left of the window title bar are greyed out. The window still moves in response to pointer drags. All of the UI in the window is greyed out and unresponsive. * The LibreOffice process spikes to about 100% CPU (range 90%..130%), in Activity Monitor. * The Close button in the bottom-right of the Extension Manager window has no effect. * Selecting menu item LibreOffice... Quit causes the Start Manager to disappear, but Extension Manager remains, hung. So does the LibreOffice process in Activity Monitor. I hope this is helpful.
Created attachment 132142 [details] LLDB Backtrace Not sure if this is helpful or not, but again some backtraces Version: 5.4.0.0.alpha0+ (enable-dbgutil build) Build ID: 221247679bcbc2507d6f904f519040fc4467d4a1 CPU threads: 4; OS: Mac OS X 10.12.4; UI render: default; Locale: en-US (en_US.UTF-8); Calc: group
I see very similar behavior to Jim DelaHunt's. I didn't track down all the details, but on ElCap with LO 5.3.3.2, I get the menubar icon for an extension upgrade. If I click on it, the upgrade window takes a while to open, then stays blank for minutes. Meanwhile LO takes up to 100% cpu and while it will respond to a quit by closing any document windows, it locks up and requires a force-quit.
Using v5.3.3.2 on Mac OS 10.12.5 I continue to have the same behaviour as described so elegantly by Jim DeLaHunt in comment 92. In trying to use the Upgrade of extensions, there was one occasion where a window popped up alluding to an Internet problem. Unfortunately, I was unable to capture the message.
Still experiencing this on 5.4beta2 (with sl langpack).
Created attachment 134464 [details] Sampling of calls when LO is unresponsive after clicking to "Enable" Zotero extension Behavior exactly as described in comment 92. On Mac OSX 10.11.6, trying to add extension for Zotero 4.0.29.15 to LO 5.2.7.2. JRE 8 v 131 is installed. Automated installation from Zotero generates the message, “An error occurred installing Zotero OpenOffice.org/NeoOffice/LibreOffice Integration.” Inspection of LO Extension Manager shows "Zotero LibreOffice Integration 3.5.9" as an extension, but: "Error: the status of this extension is unknown" with "Enable" and "Remove" options, Enable hangs as described in comment 92. Attached sample was taken after clicking the Enable button. This bug has been around for a while. It is impossible to persuade typical academic users to use OSS when connecting word processors to bibliography managers is this difficult. Please repair!
This workaround, described by Zotero, succeeded, but should be avoidable: "LibreOffice 5 on macOS 10.11+: No response from plugin Problem: LibreOffice 5 does not currently recognize the Java Runtime Environment (JRE), and Zotero's plugin therefore doesn't work. Solution: Uninstall the JRE and install the Java Development Kit (JDK) instead. Uninstall the JRE Download and install Java Development Kit (JDK) version 8 In LibreOffice: Check in Prefs → Advanced if JDK 1.8.xx is actually selected in the box Go to Tools → Extension Manager, scroll down to “Zotero LibreOffice Integration“, and click on it. You should see an “Enable” button appear. After enabling, the Zotero buttons in the LibreOffice toolbar should be responsive. Tested successfully with LibreOffice 5.2.4.2 / JDK 1.8.0_112 / LO Integration Plugin 3.5.12 / Zotero 4.0.29.16 / macOS 10.12.2." Quoted from: https://www.zotero.org/support/word_processor_plugin_troubleshooting#could_not_create_java_implementation_loader1
@WS Please do not remove important keywords like: bibisectRequest, regression. Also please do not change the version. As you can read the version in the field you changed is the earlies affected (!) and not the most recent with which the bug has happened.
"double click" and "check for updates" both confirm on MacOS 10.12.6 with ORA JDK 1.8, both cases with memory leak and unable to quit.
Time profiling using Instruments.app on my master debug build shows that : AquaSalInstance::handleAppDefinedEvent( pEvent ); at line 94 of vclnsapp.mm is being called 6125 times when an extension OXT file is drag and dropped onto a running instance (cf. enclosed screenshot).
Created attachment 135207 [details] Screenshot from OSX Instruments.app during Time Profiling
(In reply to Alex Thurgood from comment #101) > is being called 6125 times when an extension OXT file is drag and dropped > onto a running instance (cf. enclosed screenshot). In fact that figure was only for the short window of time I analyzed. If I take the whole window of time from when the OXT was dropped on the LO icon in the Dock and the moment I shut down the app, HandleAppDefinedEvent(pEvent) call fired 67529 times.
This problem is not the VCL Scheduler. The VCL OSX backend doesn't guarantee to run graphics / GUI function in the main / GUI thread, but it has to! Extension update / install runs in its own thread. So the code is actually correct, but since GUI calls runs in this thread "bad things happen" (AKA you don't see the dialog). Same happens for the "Check for updates" dialog. The solution - like most other backends (probably with the exception of headless and Gtk+) - is to run GUI changes in the main thread. I currently have an initial patch, which uses "dispatch_sync(dispatch_get_main_queue(), ..." to fix some stuff, but since this call can't return anything, it's a little bit more work, to guarantee thread-safety. This already fixes the update dialog, but the message box is currently just an empty window (but at least I can see a window now and close it ;-). I'm currently trying to understand why the message box is empty and basically reviewing all the VCL MacOS code to add more redirects, when I find insecure GUI code. (In reply to Alex Thurgood from comment #103) > In fact that figure was only for the short window of time I analyzed. If I > take the whole window of time from when the OXT was dropped on the LO icon > in the Dock and the moment I shut down the app, > HandleAppDefinedEvent(pEvent) call fired 67529 times. This is not a MacOS problem. This is a Idle job, which polls the progress bar for changes. I have a fix for that, so we just update the progress bar on changes.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9796f792fef69bbe01b674365643d1fbb79918b4 tdf#99784 OSX run GUI stuff in the main thread It will be available in 6.0.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.
Tested on Version: 6.0.0.0.alpha0+ Build ID: 80d135922d5a5d0fd0d7178935653870cecf58ea CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; Locale: fr-FR (fr_FR.UTF-8); Calc: group I downloaded the Jaguar-SQL extension (from the Extensions website). Started LO. Dragged and dropped the OXT file onto the LO Dock icon Extension installation procedure executed normally. I also tested with GallerySignauxDangers.2.1.0.oxt by downloading from the extensions website and then clicking on the OXT file from the Downloads folder in my Dock. A running LODev picked this up and started the Extensions Manager GUI, and allowed successful installation. I'd say that this is resolved fixed/ verified. Brilliant ! Many thanks !
Did you try with LanguageTool as well?
(In reply to miles from comment #107) > Did you try with LanguageTool as well? I didn't try all of the extensions out there because that wasn't the issue here. Some of the extensions that I did try and which rely on any of Python or Java for their implementation caused an immediate crash of the whole LibreOfffice process (and subsequent recovery), but they would need to filed as separate bug reports. For example, the python-based UNO inspector MRI refused to install and caused a crash. The same experience with APSO (another python-based tool) - crash, recovery, no extension installation. As for Java based extensions, I have had issues with installing some of them on LO for Mac long before the current issue was raised (see for example bug 44497).
Well, LanguageTool is one of those very popular extensions and very important for LibreOffice, IMHO. But if it is not relevant, then OK. I will wait for a Slovenian release, a 6.0 alpha due to be released in two weeks or so and if I find any errors I will reopen this issue.
Confirming the fix as well. Thanks so much Jan, for addressing this. Although it's just a collateral fix due to a re-write. @miles any issues regarding LanguageTool need to be filed in a new bug, since those are not what this bug here is about. OT: Briefly tried installing LanguageTool 3.9 on macOS 10.13 w latest LO nightly and received an error "Could not create Java implementation loader". But that is off-topic and unrelated to this issue here.
@miles Here's an existing bug about Language Tool and Libreoffice on macOS: https://bugs.documentfoundation.org/show_bug.cgi?id=75051 there may be more.
(In reply to miles from comment #109) > Well, LanguageTool is one of those very popular extensions and very > important for LibreOffice, IMHO. > But if it is not relevant, then OK. > I will wait for a Slovenian release, a 6.0 alpha due to be released in two > weeks or so and if I find any errors I will reopen this issue. FWIW, version 3.9 of LanguageTool installs just fine on: Version: 6.0.0.0.alpha0+ Build ID: 4bf3b4ee48c4e3556e257aa77940f68c13b05b54 CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; Locale: fr-FR (fr_FR.UTF-8); Calc: group
(In reply to steve -_- from comment #111) > @miles > Here's an existing bug about Language Tool and Libreoffice on macOS: > https://bugs.documentfoundation.org/show_bug.cgi?id=75051 > there may be more. Correct, that is where I added my comment after testing with master.
Don't know if relevant. I fixed this freezing problem by "Open LibreOffice→Preferences… (Mac). Click LibreOffice→Advanced (or OpenOffice→Java). Ensure that “Use a Java runtime environment” is checked, and that a JRE is selected in the list below. If no JRE appears in the list, install Java." Source: https://forums.zotero.org/discussion/37175/solved-libreoffice-plugin-wont-install
*** Bug 97399 has been marked as a duplicate of this bug. ***
*** Bug 70607 has been marked as a duplicate of this bug. ***