Summary: | Hang on accessing any pane in the application Options dialog, when Cinch is running (related to Mac OS accessibility) | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Roman Eisele <bugs> |
Component: | LibreOffice | Assignee: | Don't use this account, use tml@iki.fi <tlillqvist> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | eastasiax, michael.meeks |
Priority: | medium | ||
Version: | 3.3.0 release | ||
Hardware: | x86-64 (AMD64) | ||
OS: | macOS (All) | ||
Whiteboard: | target:3.7.0 target:3.6.3 | ||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 55571 | ||
Attachments: | Log file created by MacOS X when I had to force quit LibreOffice 3.6.2.1 because of the hang |
Description
Roman Eisele
2012-09-20 16:42:03 UTC
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! |