When Cinch, a popular window management utility for Mac OS X, is installed and running, any attempt to access any pane of the application Options dialog leads to a hang. (See “steps to reproduce” below for details!) This is very probably yet another bug in the LibreOffice code related to Mac OS X accessibility features, because * Cinch relies heavily on these accessibility features (it requires the system preference “Universal Access > Enable access for assistive devices” to be checked), and * the log file created by Mac OS X when I forced quit LibreOffice because of the hang contains many references to accessibility stuff. NB: I create a new bug report for this issue, because no one of the existing bug reports about problems accessing panes of the application Options dialog covers this special issue clearly. Steps to reproduce: ------------------- 1) Download Cinch, available from http://www.irradiatedsoftware.com/cinch/index.html (ShareWare, but you can try it for free, just as I did). 2) Start it just like a normal application. -> During startup, Cinch will automatically enable the system preference “Enable access for assistive devices” (in “System Preferences > Universal Access”) for you. 3) Optional: Rename your LibreOffice user profile folder, to preclude any influence of local settings on the test results. 4) Start LibreOffice. -> The Start Center window appears. 5) Select “LibreOffice > Preferences...” from the menu bar. -> the dialog window “Options” appears, it shows by default the first pane: “LibreOffice > User data”. 6) Now try to select any other pane from the list at the left, e.g. “General”. -> First, nothing happens; then the spinning cursor appears, LibreOffice hangs. [In the case that you *can* select another pane (I have seen this once), just try to repeat this, i.e. select yet another pane; now LibreOffice hangs.] Attached to this bug report you will find the log file created by Mac OS X when I forced quit LibreOffice because of this hang. Reproducible with: .................. * LibreOffice 3.3.0 (OOO330m19, Build:6, tag libreoffice-3.3.0.4) * LibreOffice 3.5.6.2 (Build ID: e0fbe70-dcba98b-297ab39-994e618-0f858f0) * LibreOffice 3.6.2.1 (Build ID: ba822cc) * LOdev 3.7.0.0.alpha0+, Build ID: 01e6335, Pull time: 2012-09-18 04:23:03 * and probably every other LibreOffice version. This bug is NOT identical to bug 47368, and NOT fixed by the two (three) patches for it.
Created attachment 67459 [details] Log file created by MacOS X when I had to force quit LibreOffice 3.6.2.1 because of the hang
Status NEW (confirmed) because of https://bugs.freedesktop.org/show_bug.cgi?id=49942#c6 which mentions the same problem (also involving Cinch).
Here the code ends up in an infinite loop in the same place where therr was an infinite loop after the crash fix for bug #47275... But for this case the check for a "self-parented" object that I added to break out of the loop does not work. Hmm.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3376f682a77c16f4da63dc14c45d294425e5ba8a Silly workaround for fdo#55156 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.
The above extremely ugly workaround "fixes" the problem, but is obvioously not something I would be proud of... Cherry-pick appreciated... A real fix even more appreciated, but... how much time do we want to spend on this?
*** Bug 55399 has been marked as a duplicate of this bug. ***
Tor Lillqvist committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=887f67674108b5f45e7748f6fbbf1fa0131b0ba8&g=libreoffice-3-6 Silly workaround for fdo#55156 It will be available in LibreOffice 3.6.3. 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.
Thank you very much, Tor, for all your debugging work applied to this issue, and for your patch, even if you just call it a “silly workaround”! I have tested the new workaround with a current master build: LOdev 3.7.0.0.alpha0+ (Build ID: 3f84462b, pull time: 2012-09-30 06:38:06), on Mac OS X 10.6.8 (Intel), Cinch running as required. I can confirm a big progress: there is no hang anymore (and no crash, as it was caused by another a11y-related bug); the LibreOffice “Options” dialog window is usable again even when Cinch is running. Of course, there is still a noticeable delay when changing the options pane. To see more easily what’s going on, open the Terminal, start “top”, and let it run in the background while playing with LibreOffice. My observations: * When I open the LibreOffice “Options” dialog, everything is fine (the CPU usage of the soffice process jumps only for a second or not at all). * As soon as I try to change the current options pane, there is a 1-2 seconds dealy, and the CPU usage of the “soffice” process jumps to ca. 100%. Interesting enough, it stays at that high level even after the new options pane is visible. You can “feel” this also in the LibreOffice UI: changing anything in the new options pane (e.g., typing something into an edit field, or just checking a checkbox) works very slowly. But it works, of course, and this is a big progress. * If you change the options pane again, the same thing happens: a 1-2 seconds delay, then the new options pane is visible, editing/changing anything is very slow. CPU stays at more or less 100%. * Even when I close the “Options” dialog window, and there is another LibreOffice window open (Start Center or document window), the “soffice” process first stays at 100% CPU usage; as soon as I click on the Start Center or document window so that it gets the focus, the CPU usage goes down to normal level (< 1%). * If I close the “Options” dialog window, and there is no other LibreOffice window open, not even the Start Center window (this is possible on Mac OS X, not on Win), the CPU usage immediately goes down to normal level. @ Tor (and Michael Meeks): A big progress, and the main bug (the hang) is fixed now. Great! Of course, it would be even better if we could get the CPU usage (which stays at 100% after the first options pane change) down to a normal level again; this would make it much easier to change anything in the “Options” window, and give us back a good User experience. Do you see any chance to achieve this (without too much additional work, of course)? Anyway, thank you very much!