Bug 57245 - In OS X Calc hangs if save button used when Cinch is activated (both Cmd-S and menu File->Save work OK)
Summary: In OS X Calc hangs if save button used when Cinch is activated (both Cmd-S an...
Status: VERIFIED DUPLICATE of bug 56937
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) macOS (All)
: high critical
Assignee: Not Assigned
Keywords: regression
Depends on:
Blocks: a11y-macOS
  Show dependency treegraph
Reported: 2012-11-18 09:10 UTC by Paco
Modified: 2012-12-23 19:32 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:

Calc OSX crash report (93.03 KB, text/plain)
2012-11-18 18:20 UTC, Paco
Calc OSX crash report-01 (251.32 KB, text/plain)
2012-11-18 18:32 UTC, Paco
LibreOffice 3.6.1 OSX - Writer crash if I try to use "Writing Aids" menu. (157.57 KB, text/plain)
2012-11-24 16:23 UTC, Paco

Note You need to log in before you can comment on or make changes to this bug.
Description Paco 2012-11-18 09:10:04 UTC
Version: Libreoffice 3.6.41 rc ID a9a0717

System: Mac OS X Server Lion 10.7.5 (11G63)

Description: Calc hangs if save button used. Both Cmd-G and menu File->Save works OK.  

Steps to reproduce:
1. Open Libreoffice
2. Choose new spreadsheet (or open an existing one)
3. Put something in it (or add new values)
4. Use save button in the toolbar
5. Calc hangs with 100% cpu. Need a kill to stop it. 

What additional information can I provide to help fix this?
Comment 1 Roman Eisele 2012-11-18 16:30:35 UTC
Thank you very much for your bug report!

However, on a quick test, I can NOT reproduce it with LibreOffice (Build ID: a9a0717), German langpack installed, on Mac OS X 10.6.8 (Intel). For me, the  “save” button works as expected (saves the document, if there are any changes).

> Both Cmd-G and menu File->Save works OK.
Hint: I suppose that Cmd-G is the same as Cmd-S on other localizations.

> What additional information can I provide to help fix this?
When you need to “kill” the application to make it stop -- does Mac OS X provide some crash information to you after killing the application? It shold do so; see http://wiki.documentfoundation.org/BugReport#How_to_get_debug_information_.28on_Mac_OS_X.29

If yes, please attach the log file/information provided by Apple to this bug report. With this information, we can say a bit more about this problem ...
Comment 2 Paco 2012-11-18 18:20:58 UTC
Created attachment 70225 [details]
Calc OSX crash report
Comment 3 Paco 2012-11-18 18:32:04 UTC
Created attachment 70227 [details]
Calc OSX crash report-01
Comment 4 Paco 2012-11-18 18:35:15 UTC
Thank you for your quick response :-)

While I was collecting the report on my mac, my wife´s Calc crashed too. 

Her version is on OSX too. 

I hope those two reports can help you find some light in this bug. :-)
Comment 5 Alex Thurgood 2012-11-18 18:53:20 UTC
Definitely not reproducible on 3.6.3, and last time I loaded a Calc document in my master build (from 3 days ago), couldn't reproduce a crash in this way either. I haven't tried with 3.6.4 rc1, and probably won't because it means juggling with too many user configs, it is bad enough having to separate out 3.3.4, 3.5.x, 3.6 and LOdev, and have some of them interfere with each other.

There's a lot of stuff going in Accessibility, and you seem to have something called TestRunner installed. A quick search says that this is a Cocoa application testing program on Mac (various other programs by the same name seem to be available for other OSes).

This testrunner is stress testing the Accessibility API by the looks of it, and that might be what is causing the crash (at a wild guess).

Comment 6 Alex Thurgood 2012-11-18 19:06:01 UTC
I see we have TestRunner in our aqually code :

vcl/aqua/source/a11y/aqua11ywrapper.mm:Reference < XAccessibleContext > hitTestRunner ( com::sun::star::awt::Point point,
vcl/aqua/source/a11y/aqua11ywrapper.mm:                    Reference < XAccessibleContext > myHitChild = hitTestRunner ( point, rxAccessibleChild -> getAccessibleContext() )
vcl/aqua/source/a11y/aqua11ywrapper.mm:                            hitChild = hitTestRunner ( hitPoint, rxAccessible -> getAccessibleContext() );
vcl/aqua/source/a11y/aqua11ywrapper.mm:        hitChild = hitTestRunner ( hitPoint, mpReferenceWrapper -> rAccessibleContext )

but I have no idea what this does.

Comment 7 Alex Thurgood 2012-11-18 19:06:57 UTC
Forgot to mention that I'm on OSX 10.8, so maybe specific bug on Lion ?

Comment 8 Emir Sarı 2012-11-18 21:21:26 UTC
Not reproducible on 10.7.5,
Comment 9 Niklas Johansson 2012-11-19 08:47:27 UTC
Not able to reproduce on Mac OS X Lion 10.7.5 with LibreOffice rc ID a9a0717. Tried it with VoiceOver active as well, without being able to reproduce.
Comment 10 Roman Eisele 2012-11-20 18:18:15 UTC
@ Paco:
Thank you very much for the crash reports!

@ Alex, Emir, Niklas:
Thank you very much for triaging!

@ Alex:
Thank you for your research!

Paco’s crash reports which contain many references to Mac OS X accessibility stuff -- especially the hitTestRunner() only appears when the Mac OS X accessibility API is used -- show that this is yet another bug in some LibreOffice code which gets activated only when the Mac OS X accessibility API is used.

Therefore I have added this bug to our tracking bug for such issues, bug 55571 (please see that bug report for more details about this bugs and its fellows).

And for the same reason I have lowered the severity a bit: the bug is critical, but not a blocker -- being an issue related to Mac OS accessibility, this bug should have a workaround: disably any utilities which activate the usage of the Mac OS X accessibility API ...
Comment 11 Roman Eisele 2012-11-20 18:18:30 UTC
@ Paco:

To work around the bug and to find out what exactly triggers the bug,
please check and answer the following questions:

1) Do you have any accessibility features enabled? Apple’s accessibility
features like “VoiceOver” or “Enable access for assistive devices”, which get
enabled in “System Preferences > Universal Access”, are known to cause many crashes and freezes in LibreOffice. So please try to disable any accesibility features, then check if the problem is still reproducible.

2) Do you have installed any window management/user interface utilities/apps/control panels/extensions for Mac OS X like 
   * AquaSnap                * BetterSnapTool
   * BetterTouchTool         * Breeze
   * Cinch                   * Divvy
   * DoublePane              * Flexiglass
   * HyperDock               * iSnap
   * Moom                    * RightZoom
   * ShiftIt                 * SizeUp
   * SizeWell                * Spectacle
   * Stay                    * TileWindows
   * WindowTidy            ... or something similar?

And/or do you use any mouse cursor/pointer utility, i.e. some little application or control panel etc. which animates or replaces etc. the mouse curser/pointer, like
   * LazyMouse?

And/or do you use any special software which could be related to accessibility stuff, e.g. a screen reader, screen magnifier, speech recognition software,
a text-to-speech (dictation) application, or similar?

All these and many similar utilities rely heavily on Mac OS accessibility features and therefore can cause LibreOffice to crash or freeze. So please check if you have installed any utility of this kind and try to disable it
(or to add LibreOffice to the list of excluded applications for the utility,
if there is such a thing).

So please check these possibilities, if any of them helps to make the hang go away, and report the results here.

Thank you very much in advance!
Comment 12 Paco 2012-11-20 18:56:00 UTC
Hi Roman 

I have this settings in “System Preferences > Universal Access”

"VoiceOver" -> No
"Enable access for assistive devices"-> Enabled/Checked

Unchecking "Enable access for assistive devices" RESOLVES THE CRASH both in my Mac and my wife's. 

Thank you all for your support. :-)
Comment 13 Paco 2012-11-20 20:12:03 UTC
Hi again 

As Roman said before, I "was" using Cinch, so now that I have disabled "Universal Access" the app no longer works :-(
Comment 14 Roman Eisele 2012-11-21 14:56:14 UTC
@ Paco:
Thank you very very much for testing and reporting your results! Now we know what has triggered this bug ...

But disabling “Enable access for assistive devices” and/or Cinch is not a fix, it is a mere workaround (LibreOffice should not crash even with this option checked and Cinch installed), so we can’t mark this as RESOLVED/FIXED. Rather I set the status of this bug report to REOPENED, because I can reproduce it now:

REPRODUCIBLE on Mac OS X 10.6.8 (Intel) with Cinch activated/running and therefore the Universal Access option “Enable access for assistive devices” checked,
* with LibreOffice (Build ID: da8c1e6),
* with LibreOffice (Build ID: 58f22d5),
* with LibreOffice (Build ID: a9a0717),
* with the newest master build for Mac OS X:
  LOdev (Build ID: 740767; pull time: 2012-11-20 10:26:54).

But I can NOT reproduce this issue on the same machine with Cinch running etc.
* with LibreOffice (Build-ID: 3fa2330-e49ffd2-90d118b-705e248-051e21c)
* with LibreOffice (Build ID: e29a214)

So this bug is a regression, introduced between the releases of and; therefore I add the keyword “regression” and set the Version field to the oldest version which is know to contain the bug (as usual).
Comment 15 Roman Eisele 2012-11-21 15:20:47 UTC
When has this regression been introduced? After testing various 3.6/3.7 daily builds, we got it:

The bug is NOT reproducible with
LOdev (Build ID: cfbfa26; pull time: 2012-09-07 10.35.10)
But it is FIRST reproducible with
LOdev (Build ID: c303961; pull time: 2012-09-11 08.49.57)
i.e. the bug was introduced by some patch committed to the 3.6 branch between 2012-09-07 10.35.10 and 2012-09-11 08.49.57.

But the most important changes in that short time frame where the two fixes for bug 47368, which fixed many other problems related to Mac OS X accessibility.
So I fear that -- horribile dictu -- this present bug is a negative side-effect of one of our two important patches which fixed bug 47368:




just like bug 55671, which seems to have been introduced by one of these patches, too ...
Comment 16 Paco 2012-11-21 16:34:31 UTC
Hi Roman 

I can confirm that LibreOffice (Build ID: e29a214) WORKS OK on my machine with Cinch activated. 

I am glad to have a release that works. Please, tell me if there is anything I can do to help you again. 

Thank you all for a great work :-)
Comment 17 Kohei Yoshida 2012-11-21 19:03:44 UTC
Changing the component. This is technically not a Calc regression, but is one in the accessibility framework.
Comment 18 Paco 2012-11-24 16:23:05 UTC
Created attachment 70525 [details]
LibreOffice 3.6.1 OSX - Writer crash if I try to use "Writing Aids" menu.

Sorry to bring some more bad news :-(

I don't know if this is another different bug, so I'll add it here. 

With Build ID: e29a214 Writer crash if I try to use "Writing Aids" menu. 

Crash report "LibreOffice OSX crash report-03.txt" attached.
OS Version:      Mac OS X Server 10.7.5 (11G63)
- Cinch IS ACTIVE, so Universal Access is enabled.
- Calc Save button works OK
- Libreoffice->Preferences->Language Settings->Writing Aids CRASH LibreOffice.

Steps to reproduce:
1. Open a new Writer file
2. Select Libreoffice->Preferences->Language Settings->Writing Aids
3. Add a new personal dictionary (or change any option there)
4. Click on Languages option (on the left) or Click OK  (1)
5. LibreOffice crashes

(1) Sometimes the crash triggers clicking OK, others simply trying to select "Writing Aids", or another option in "Language Settings", but I think that selecting "Writing Aids" is a prerequisite to trigger the crash. When LO restarts, if I open the "Language Settings" option and "Writing Aids" is already selected, the crash is not triggered until I change something and click OK, or click on another option, or...
Comment 19 Roman Eisele 2012-11-25 16:27:41 UTC
Hi Paco --

(In reply to comment #18)
> Sorry to bring some more bad news :-(
> I don't know if this is another different bug, so I'll add it here. 
> With Build ID: e29a214 Writer crash if I try to use "Writing Aids"
> menu. 

Yes, this is a different bug. From your description, and from the stack trace in the log file, I conclude that it is essentially the same issue as bug 46981 and bug 52147, which are both in turn variants of bug 47368. (For details about these older bug reports and their relations, see attachment 67635 [details].)

Now bug 47368 has been fixed (together with its variants), but it seems that the fixes for bug 47368 have, as an unwanted side-effect, introduced a new bug -- the present one, as described in your original comment #0.

This leads to a dilemma: if you use LibreOffice <=, you will suffer bug 47368 and its variants; if you use LibreOffice >=, you will suffer the present bug :-( And switching to Apache OpenOffice is not a solution, too, because AFAIK it suffers from bug 47368, too ...

So I am sorry to say so, but: for now, the only workaround is to disable or deinstall Cinch. If you do not use Cinch nor any similar tools (see my -- incomplete -- list in comment #11), neither bug 47368 and its variants nor the present bug nor some similar accessibility-related bugs will appear. This is a poor situation, but the only consolation I can give for now is that LibreOffice is not the only application which has problems with Mac OS accessibility and tools which need it: IIRC, some really expensive DTP/graphics/digital imaging applications have (or at least had) very similar problems ...

A simple workaround would be to deactivate Cinch for LibreOffice *only*, if that was possible; but it seems that Cinch does not have a list of applications to exclude. Some similar tools, e.g. “RightZoom” and “BetterSnapTool”, allow to be disabled for certain applications; maybe it could help you to try if any of these utilities (a) satisfies your needs and (b) adding LibreOffice to the exclusion list in that application really makes the crashes go away. But this is just a hint, intended to be helpful, and no advertising for nor negative advertising against Chinch, RightZoom, and BetterSnapTool etc. ;-)

Hope it helps!
Comment 20 Paco 2012-11-25 16:47:08 UTC
Hi Roman 

Thank you again for your response. 

I think I'll deal with disabling Cinch every time I'll need to touch "Writing Aids" menu in LO. Not a bad deal, after all :-)
Comment 21 Michael Meeks 2012-12-18 13:32:10 UTC
Anything with this in the trace:

   17 hitTestRunner(com::sun::star::awt::Point, com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessibleContext>) + 433 (in libvcllo.dylib) [0x23e61f1]
                                                                          17 ScAccessibleTableBase::getAccessibleChild(long) + 131 (in libsclo.dylib) [0x2ec94513]

is a duplicate of bug#56937 which needs someone to help test/compile the fix :-)

Thanks for the nice report !

*** This bug has been marked as a duplicate of bug 56937 ***
Comment 22 Roman Eisele 2012-12-23 17:20:13 UTC

I can no longer reproduce this bug beginning with the 1st available master build after the patch for bug 56937 has been committed:
  Version (Build ID: 413d1a932eb4c47510dd05905c1ff467cb186d0)
  TinderBox: MacOSX-Intel@1-built_no-moz_on_10.6.8, Branch:master,
  Time: 2012-12-19_04:13:37

This means that the present bug is really a duplicate of bug 56937, and was fixed by the same commit.

Tested on Mac OS X 10.6.8 (Intel), with Cinch installed and active.

@ Michael Meeks:
Thank you very much again for fixing bug 56937 (and all its instances, like this one)!
Comment 23 Paco 2012-12-23 19:32:28 UTC
Hi all :-)

I can also confirm that this bug is no longer present in my system with

LOdev Version (Build ID: 19340f79a8e8fbd291d1b431848ad7c44aacded)
TinderBox: MacOSX-Intel@1-built_no-moz_on_10.6.8, Branch:master, Time: 2012-12-22_23:55:42

and Cinch active.

Thank you all (specially to Michael Meeks) for a terrific work resolving this.

Happy new year for you all :-)