Bug 95573 - EXTENSION MANAGER - freeze / hang when attempting to install extensions on OSX 10.11, installation confirmation dialog not displayed
Summary: EXTENSION MANAGER - freeze / hang when attempting to install extensions on OS...
Status: RESOLVED DUPLICATE of bug 99784
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Extensions (show other bugs)
Version:
(earliest affected)
4.4.5.2 release
Hardware: x86-64 (AMD64) Mac OS X (All)
: highest critical
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: target:5.1.1
Keywords: bibisectRequest, haveBacktrace, regression
: 97399 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-11-04 16:23 UTC by shunesburg69
Modified: 2016-10-25 19:17 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
lldb output (5.78 KB, text/plain)
2015-11-04 18:18 UTC, Alex Thurgood
Details
unopkg lldb output plus backtrace (23.39 KB, text/plain)
2016-01-05 18:04 UTC, Alex Thurgood
Details
SAL_LOG from Fedora 23 (85.20 KB, application/x-xz)
2016-01-07 11:10 UTC, Maxim Monastirsky
Details
SAL_LOG from OSX 10.11.2 (515.51 KB, application/zip)
2016-01-07 15:42 UTC, Alex Thurgood
Details
backtrace 1 (151.38 KB, text/plain)
2016-01-13 13:56 UTC, Maxim Monastirsky
Details
backtrace 2 (140.57 KB, text/plain)
2016-01-13 13:57 UTC, Maxim Monastirsky
Details

Note You need to log in before you can comment on or make changes to this bug.
Description shunesburg69 2015-11-04 16:23:24 UTC
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.
Comment 1 shunesburg69 2015-11-04 16:34:10 UTC
I try lot version of LO and I reset my configuration every time.
Comment 2 Alex Thurgood 2015-11-04 17:46:26 UTC
@shunesburg : please indicate which version of LibreOffice you are using and whether it is AppStore or TDF download
Comment 3 shunesburg69 2015-11-04 17:49:27 UTC
I use only the TDF LO.
I try with the 4.4 and the 5.0, the both can't install any addon.
Comment 4 Alex Thurgood 2015-11-04 17:57:20 UTC
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.
Comment 5 Alex Thurgood 2015-11-04 18:06:52 UTC
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
Comment 6 Alex Thurgood 2015-11-04 18:18:48 UTC
Created attachment 120267 [details]
lldb output
Comment 7 Alex Thurgood 2015-11-04 18:21:14 UTC
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.
Comment 8 Alex Thurgood 2015-11-04 18:33:18 UTC
@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.
Comment 9 Michael Meeks 2015-11-04 20:01:47 UTC
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 !
Comment 10 shunesburg69 2015-12-13 00:30:44 UTC
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.
Comment 11 Martin Srebotnjak 2015-12-31 11:26:31 UTC
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.
Comment 12 Michael Meeks 2016-01-01 13:55:39 UTC
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 ?
Comment 13 Alex Thurgood 2016-01-05 17:21:34 UTC
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.
Comment 14 Michael Meeks 2016-01-05 17:28:16 UTC
Hi Alex; nice debugging - can you get stack traces (even roughly) of all the live threads ? =)

Thanks !
Comment 15 Alex Thurgood 2016-01-05 17:29:02 UTC
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.
Comment 16 Alex Thurgood 2016-01-05 17:30:39 UTC
(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 ?
Comment 17 Alex Thurgood 2016-01-05 18:04:21 UTC
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.
Comment 18 Michael Meeks 2016-01-05 20:07:04 UTC
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 ?
Comment 19 Alex Thurgood 2016-01-06 12:23:40 UTC
(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)
Comment 20 Michael Meeks 2016-01-06 12:49:34 UTC
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 !
Comment 21 Maxim Monastirsky 2016-01-06 13:45:10 UTC
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.
Comment 22 Alex Thurgood 2016-01-06 17:59:40 UTC
(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 ?
Comment 23 Michael Meeks 2016-01-07 10:12:38 UTC
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 !
Comment 24 Maxim Monastirsky 2016-01-07 11:10:14 UTC
Created attachment 121772 [details]
SAL_LOG from Fedora 23
Comment 25 Alex Thurgood 2016-01-07 15:42:14 UTC
Created attachment 121785 [details]
SAL_LOG from OSX 10.11.2
Comment 26 Martin Srebotnjak 2016-01-12 19:14:54 UTC
Shouldn't this be a stopper/blocker for 5.1?
Comment 27 Michael Meeks 2016-01-12 23:00:26 UTC
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 !
Comment 28 Maxim Monastirsky 2016-01-13 13:56:32 UTC
Created attachment 121898 [details]
backtrace 1
Comment 29 Maxim Monastirsky 2016-01-13 13:57:01 UTC
Created attachment 121899 [details]
backtrace 2
Comment 30 Maxim Monastirsky 2016-01-13 13:58:01 UTC
Why the progress bar is updated, if I didn't accept the installation yet?
Comment 31 Michael Meeks 2016-01-13 14:34:19 UTC
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.
Comment 32 Commit Notification 2016-01-13 14:35:26 UTC
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.
Comment 33 Michael Meeks 2016-01-13 14:36:01 UTC
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.
Comment 34 Maxim Monastirsky 2016-01-13 17:05:31 UTC
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.
Comment 35 Alex Thurgood 2016-01-14 15:48:22 UTC
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...
Comment 36 cwvb 2016-01-16 10:41:45 UTC
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.
Comment 37 Commit Notification 2016-01-25 17:15:44 UTC
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.
Comment 38 steve -_- 2016-01-27 10:23:35 UTC
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)
Comment 39 Vincent Boudry 2016-02-12 10:04:21 UTC
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.
Comment 40 Michael Meeks 2016-02-13 19:37:17 UTC
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.
Comment 41 shunesburg69 2016-02-22 17:40:02 UTC
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.
Comment 42 shunesburg69 2016-02-22 17:41:41 UTC
(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.
Comment 43 steve -_- 2016-02-24 10:51:14 UTC
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.
Comment 44 Michael Meeks 2016-02-24 13:28:55 UTC
> 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.
Comment 45 Alex Thurgood 2016-03-03 08:59:44 UTC
*** Bug 97399 has been marked as a duplicate of this bug. ***
Comment 46 Alex Thurgood 2016-03-03 09:43:05 UTC
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
Comment 47 Martin Srebotnjak 2016-03-03 09:46:10 UTC
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.
Comment 48 shunesburg69 2016-03-18 18:10:24 UTC
I think the bug https://bugs.documentfoundation.org//show_bug.cgi?id=70607 is related to this one.
Comment 49 Buovjaga 2016-05-08 08:14:00 UTC
REOPENED is wrong status as we have an older report about the other issue. Reverting status change.
Comment 50 Michael Meeks 2016-05-09 08:35:42 UTC
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.
Comment 51 shunesburg69 2016-05-09 10:46:40 UTC
@ Alex Thurgood
We can bypass with the "Add" button, but it's not a resolution, it's just a tip.
Comment 52 Buovjaga 2016-05-09 10:54:25 UTC
Let's leave status as FIXED, ok..
Comment 53 shunesburg69 2016-05-09 10:58:12 UTC
But is false, it doesn't.
Comment 54 Buovjaga 2016-05-09 11:00:30 UTC
(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.
Comment 55 shunesburg69 2016-05-09 11:07:50 UTC
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.
Comment 56 shunesburg69 2016-05-09 11:12:22 UTC
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".
Comment 57 steve -_- 2016-05-11 09:40:15 UTC
@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.
Comment 58 shunesburg69 2016-05-11 10:28:32 UTC
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.
Comment 59 steve -_- 2016-05-11 10:35:06 UTC
@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?
Comment 60 shunesburg69 2016-05-11 20:24:01 UTC
You have right but I'm afraid if I made a new one, the bug should flag as a duplicate.
Comment 61 shunesburg69 2016-05-11 20:32:45 UTC
I made a new one (Bug 99784).
Comment 62 shunesburg69 2016-05-11 21:19:18 UTC

*** This bug has been marked as a duplicate of bug 99784 ***