I can't install any extension since I upgrade on El Capitan (OS X 10.11) because the add-on manager freeze when I try.
I try lot version of LO and I reset my configuration every time.
@shunesburg : please indicate which version of LibreOffice you are using and whether it is AppStore or TDF download
I use only the TDF LO. I try with the 4.4 and the 5.0, the both can't install any addon.
Thanks. Well, I managed to install the Danger Sign gallery extension on Version: 5.0.2.2 Build ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe Locale : fr-FR (fr.UTF-8) but something is indeed not right. If I drag and drop an extension file onto the StartCenter, the Extension Manager UI launches and attempts to start the installation of the extension, but then appears to freeze indefintely, yet OSX doesn't see this as a hung app. When I tried to force quit the application via the Dock, I then a request to confirm installation of the extension. If I OK that request, the extension is then installed, so it would seem that the confirmation dialog is not displayed when it should be, or rather it is hidden from the user. Further testing required to nail down the exact problem.
Confirming - tried with another gallery extension, the problem was even worse. Context switching seems to help a little, but I couldn't ever get the confirmation to install dialog to appear. This worked previously in OSX 10.10 ==>> regression
Created attachment 120267 [details] lldb output
okay, so context switching between desktops and other apps, eventually allows the confirmaiton dialog to be displayed, and then activated, but the whole LibreOffice app seems to grind to a hal and become unresponsive. I have enclosed the lldb output from my debug master build, hopefully that should enable one of the devs to see what is going wrong.
@Michael: there's a lot of vcl calling in that lldb output, any idea ? when I'm in lldb and the freeze occurs in LO, I don't have access to input any commands to lldb (or at least, I haven't found a way of doing so), lldb appears to be waiting for the LO process to return some further token of information, which never happens (well, at least not until I can regain the focus of the app when the confirmation dialog OK button press is finally accepted.
Looks odd; I'd love to see it bibisected (if we have a suitable repo). Sadly there is no easy environment variable for disabling grabs on Mac (that I know of). Also - any chance of a stack trace with debugging symbols (of all threads ?) =) thanks !
There is something new? A patch or a future commit? It will be good if the bug could be solved before the 5.1 release.
Noticed this before but now looking at it it seems to have gone to far: Clicking "Check for updates" in Extensions Manager on OSX in 5.1RC1 takes ages to check for updates of already installed extensions. I never got it to finish so it might be just stuck. The Extensions Manager just gets unresponsive. Since this could signal a problem of some kind of Internet connection, I manually downloaded LanguageTool 3.2 and installed it in Extension Manager manually over 3.1 by clicking "Add...". And again this installation takes ages, after more than 10 minutes the status is stuck somewhere around 10 % in the graphic representation ... The fans of the laptop started to work so it seems there is some "hard computational work" happening somewhere. Cannot figure out what is happening, but it obviously it is not due to Internet firewall or anything like that. I tried the same with LibreOffice Vanilla 5.0.2.2 (for OSX, the Collabora version in the iTunes) and I am seeing the same problems with updating included spelling/thesaurus extensions (LT cannot be installed since Vanilla does not support use of Java, so I cannot check that). I guess there is some serious error in the updating/checking for updates of extensions on OSX and this is a serious functionality flaw, that should be marked as a stopper on OSX, IMHO.
Relatively few of us have Macs unfortunately; making this hard to test. I suspect some threading / event madness - provoked by the new main-loop work. Can you get a dbgutil build and get a log file with SAL_LOG=1 set - or at least the vcl.schedule log domain (both warn and info) is what I'm most interested in =) Norbert, and/or Andras - is that something that's easy to get ?
So, testing this again on my latest master dbgutl build (20160104) I started unopkg gui in a lldb session. I was able to add an extension package, e.g. BaseTools-0.0.5.oxt The extension installed for all users successfully, there was no stall or freeze. I then tried clicking on the Check for updates button, which gave the following console output : warn:sal.osl:60084:4:sal/osl/unx/socket.cxx:951: undefined address and that is when the GUI freezes. Normally, what should happen is that a window is drawn with a list of all available updates, or else an empty window if none are available. However, this window never gets drawn, and that is why the app appears frozen. lldb remains in an expectant state, apparently waiting for something to happen, but not returning to the active debugging cli (how do I get that back, forcibly, if necessary, to input commands ?) The Mac process monitor app shows that LO has 5 running threads, and is occupying approximately 1.5% CPU, but dropping to 0% when switching context away from app. What I do notice in the Memory usage tab of the Monitor.app, is that the LO process has spawned 238 ports !! However, none of these ports appear to have had any network traffic.
Hi Alex; nice debugging - can you get stack traces (even roughly) of all the live threads ? =) Thanks !
In that previous test, I left LOdev running a full 6 minutes with no activity, in a seemingly frozen state. None of the buttons on the dialog would respond, I couldn't close the dialog by any means, I couldn't even quit LOdev via the normal menu entry or the dock entry. I had to force quit the app to regain lldb cli debugging control.
(In reply to Michael Meeks from comment #14) > Hi Alex; nice debugging - can you get stack traces (even roughly) of all the > live threads ? =) How do I do that, lldb doesn't allow me to input anything from the cli session when LOdev is in that state ?
Created attachment 121737 [details] unopkg lldb output plus backtrace So, forcing a break and killing the process allowed me to return to lldb and request a bt. Had to repeat this though, as lldb re-enters a kind of zombie mode, so the bt output might not be relevant to the particular state.
Very odd, the trace you give seems to suggest that there are two dialogs concurrently running, one in each thread: frame #7: 0x000000010974b943 libdeploymentgui.dylib`dp_gui::UpdateDialog::Execute(this=0x0000000106244000) + 83 at dp_gui_updatedialog.cxx:600 and frame #14: 0x00000001097280f7 libdeploymentgui.dylib`dp_gui::ServiceImpl::startExecuteModal(this=0x0000000108bdce70, xListener=0x00007fff5fbff3f0) + 2807 at dp_gui_service.cxx:284 Which is somewhat interesting and unusual in itself; that 'bWait' is set is good - the app is waiting for events to do something. Are you sure there is no hidden window somewhere ? perhaps the transience / layering is wrong for them somehow ?
(In reply to Michael Meeks from comment #18) > Are you sure there is no hidden window somewhere ? perhaps the transience / > layering is wrong for them somehow ? Therein lies the problem - the window although initiated, is never displayed. In my testing with just unopkg (which of course starts an instance of the office in the background and causes the LO icon to appear in the dock), I had just two windows on my screen, the lldb terminal session and unopkg gui window - no amount of context switching, or moving windows around the desktop could make the update check window appear. I fear it is the same for the confirmation dialog window that is supposed to be displayed when installing an extension (as was reported initially in this bug report). Quite why these windows do not appear, or at least do not appear in a sufficient time frame for the user not to give up on the whole experience and kill the office, is beyond my knowledge. It could be the same or similar bug as that which afflicts the first opening of the Finder dialog when attempting a first open or save of a document after launch of LO (see bug 90913)
Hi Alex - thanks so much for persisting =) can we take a new approach ? I'd love to see the output from: export SAL_LOG=1 on a dbgutil build. That should show us what the scheduler and quartz backends are doing - either for this case, or for the file-selector one. That is assuming you have a dbgutil build somewhere ? Thanks !
I can reproduce the freeze under Fedora 23 too, if installing extensions using File->Open, instead of opening the extension manager first. Reproduced with my own 5.1/master builds, and only with gtk/gtk3 vclplugs, not with gen. Oddly I reproduce the same with Fedora's 5.0.4.2, but not with TDF's 5.0.4.2, nor with my own 5-0 build. Can be of course unrelated to the Mac problem.
(In reply to Michael Meeks from comment #20) > Hi Alex - thanks so much for persisting =) can we take a new approach ? I'd > love to see the output from: > > export SAL_LOG=1 > > on a dbgutil build. That should show us what the scheduler and quartz > backends are doing - either for this case, or for the file-selector one. > That is assuming you have a dbgutil build somewhere ? > > Thanks ! Hi Michael, yes, I have a dbgutil build, but where do I stick the export SAL_LOG=1 ? Do I add it to the sofficerc or some other file or is this something I can pass to lldb in some way ?
Oh - you need the SAL_LOG in the environment - so I guess run from a shell and do: export SAL_LOG=1 and then re-direct the output of LibreOffice to a file; no idea how to do that on Mac but on Linux: SAL_LOG=1 soffice >& /tmp/sal-log.txt Maxim - could you do the same ? - it'd be great to have that log. Thanks !
Created attachment 121772 [details] SAL_LOG from Fedora 23
Created attachment 121785 [details] SAL_LOG from OSX 10.11.2
Shouldn't this be a stopper/blocker for 5.1?
Maxim - your linux trace seems to show a live loop - most likely caused by an Invalidate occuring during the Paint of a Window. Any chance you could put a breakpoint in vcl/source/window/paint.cxx (Window::ImplInvalidate) - and get some stack-traces from there - when it is live-locked ? That would give the same symptoms (of not making progress) that we see on Mac, but the mac trace doesn't show the same symptoms - oddly. Thanks !
Created attachment 121898 [details] backtrace 1
Created attachment 121899 [details] backtrace 2
Why the progress bar is updated, if I didn't accept the installation yet?
Lovely; thanks Maxim ! =) there is (in a nutshell) a busy loop re-setting the progress bar's status there from an idle handler; not great ! but then again the priority of that idle handler is low so it shouldn't -really- affect rendering or making progress here I think - I'm surprised that it seems to. And - wow, this code is just horrific =) again a load of state being updated at 'idle' (ie. now in a busy loop) that is simply not changed from one iteration to the next. Horrors. IMPL_LINK_NOARG_TYPED(ExtMgrDialog, TimeOutHdl, Idle *, void) and the cut/paste coded: IMPL_LINK_NOARG_TYPED(UpdateRequiredDialog, TimeOutHdl, Idle *, void) are inexcusable bad.
Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5077a1f66411efd78110206343b07fa6ff8d58b0 tdf#95573 - stop (crazy) busy loop from blocking rendering. It will be available in 5.2.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.
Pushed a workaround to master, and a patch for -5-1 to CI: https://gerrit.libreoffice.org/21436 testing much appreciated; since I can't easily test please close if it works for you =) Beyond that this dialog code needs a significant re-write; will create an easy-hack.
Thanks Michael, now at least I can click OK to accept the install. But still, the message box respond/redraw is _very_ slow, with a relatively high CPU usage.
On Version: 5.2.0.0.alpha0+ Build ID: ac91a81b7b47fc9eba24455d34e2168309ea51d1 CPU Threads: 2; OS Version: -; UI Render: default; Locale: fr-FR (fr.UTF-8) I still don't get a window when I click on Check for Updates...
on LO v 5.0.4.2 extension manager starts but is greyed out and doesn't do anything. LO Menues are readable, but application seems to (be busy?) hang. MAC OS 10.11.2 does not say: 'Application isn't answer' in 'Immediatly Finish' - Dialog. (I am german, may be the name of this feature is different. But you can call it by cmd+alt+esc. I can't install any extension and it is not possible to update the rest of installed extentions.
Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a4dfb5a24ea16c6071dc40aa7321a5118745cb4b&h=libreoffice-5-1 tdf#95573 - stop (crazy) busy loop from blocking rendering. It will be available in 5.1.1. 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.
Confirming what Alex found out in his tests: Checking for updates does not open any window and nothing happens. Also can't close the Extension manager once the "Check for updates" has been initiated. Hope this can be addressed. Version: 5.2.0.0.alpha0+ Build ID: 31ad2d7af585e8f35a645482a92bdc37a66e64ca CPU Threads: 4; OS Version: Mac OS X 10.11.3; UI Render: default; TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2016-01-25_23:36:12 Locale: de-DE (de.UTF-8)
the daily update (libreoffice-5-1/MacOSX-x86_64@49-TDF/2016-02-09_23.51.09) doesn't change anything: no update of extension, impossibility to close the extension window (or LO) once the "update" button has been pressed.
Hmm; the check for updates window is opened in a new thread; which inevitably causes problems. I'd strongly prefer to close this bug; and have a new clean bug that's easy for me to catch up with with the limited time I have here. I need some new back-traces, with debugging symbols, of all threads when it is hung & not showing anything. Ideally also - I'd have some SAL_LOG=1 output (as we had for fedora above) from a dbgutil build to see what the scheduler is doing. Without that, and without being able to reproduce it (no Mac) it's hard to get further. ATB.
We can just close the bug like that and ignoring all mac users. If you need logs or something else said us what to do.
(In reply to shunesburg69 from comment #41) > We can just close the bug like that and ignoring all mac users. If you need > logs or something else said us what to do. Sorry I mean "We can't just close" not "We can just close". I'm not English native sorry.
Agree. meeks said "I need some new back-traces, with debugging symbols, of all threads when it is hung & not showing anything." Can someone link precise steps how to produce that debugging info? Otherwise chances are really low, users will be able to produce the requested info.
> We can't just close the bug like that and ignoring all mac users. Opening a new, clean bug that isn't packed with irrelevant stuff; and is focused on the separate issue that is not fixed is rather important. > If you need logs or something else said us what to do. As & when there is a new bug, that is focused on the remaining issue - I might find some time to look at this again. Until then; I'm off. Please do CC me on the new bug. As/when this one is closed =) wrt. generating back-traces; there is a lot of documentation on this around the place that google can find: https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg Thanks.
*** Bug 97399 has been marked as a duplicate of this bug. ***
Installing new extensions via the add button works in Version: 5.2.0.0.alpha0+ Build ID: 144ce8b3ff38a39507a4167662ef5b4aec63907a Threads CPU : 2; Version de l'OS :Mac OS X 10.11.3; UI Render : par défaut; Locale : fr-FR (fr.UTF-8) Closing this bug as FIXED. I have opened a new bug report for the Update hang scenario under bug 98376
please backport the fix from 5.2.0.0 to 5.1.x, it is going to be the stable version for a long time (and this is the most "unstable" bug there can be). I would like to reopen until it is fixed in 5.1.x. Thanks, m.
I think the bug https://bugs.documentfoundation.org//show_bug.cgi?id=70607 is related to this one.
REOPENED is wrong status as we have an older report about the other issue. Reverting status change.
Hi Alex - fun - so - is there any chance we can bibisect the -fix- out of the 5.2 / development branch =) then we can back-port it; it is unclear what (beyond my work) fixed this I guess.
@ Alex Thurgood We can bypass with the "Add" button, but it's not a resolution, it's just a tip.
Let's leave status as FIXED, ok..
But is false, it doesn't.
(In reply to shunesburg69 from comment #53) > But is false, it doesn't. One issue per report. What you are talking about is bug 70607, not this.
It's me who made this report at beginning, and I speak about "install", not update. It's possible that is linked but it's not the same bug.
In the title of my report I don't see any word about update: "EXTENSION MANAGER - freeze / hang when attempting to install extensions on OSX 10.11, installation confirmation dialog not displayed".
@shunesburg69 I verified this bug is fixed: 1. download example extension (I used http://extensions.libreoffice.org/extension-center/copy-only-visible-cells) 2. open LO extension manager and click "add" 3. selected downloaded extension → installs fine on 10.11.4 with LO latest master from yesterday. VERIFIED FIXED If I am missing something please elaborate, but do not change the bug status.
I said it before "Add" button is OK but it's not the usual way to install an addon. When you double click on oxt file, the extension manager try to install but freeze.
@shunesburg69@yahoo.fr Confirmed. Although this may seem odd, it would be really helpful if you could file a new clean bug with exact repro steps about ths issue. I am happy to confirm the new bug since what you write is correct. But this bug here with almost 60 comments, no proper repro steps in the initial report and a misleading title will neither help you, devs or QA. It will just continue to raise frustration. Would that be ok with you to file a new bug?
You have right but I'm afraid if I made a new one, the bug should flag as a duplicate.
I made a new one (Bug 99784).
*** This bug has been marked as a duplicate of bug 99784 ***