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?
Thank you very much for your bug report!
However, on a quick test, I can NOT reproduce it with LibreOffice 18.104.22.168 (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 ...
Created attachment 70225 [details]
Calc 22.214.171.124 OSX crash report
Created attachment 70227 [details]
Calc OSX 126.96.36.199 crash report-01
Thank you for your quick response :-)
While I was collecting the report on my mac, my wife´s Calc crashed too.
Her version is 188.8.131.52 on OSX too.
I hope those two reports can help you find some light in this bug. :-)
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).
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.
Forgot to mention that I'm on OSX 10.8, so maybe specific bug on Lion ?
Not reproducible on 10.7.5, 184.108.40.206
Not able to reproduce on Mac OS X Lion 10.7.5 with LibreOffice 220.127.116.11 rc ID a9a0717. Tried it with VoiceOver active as well, without being able to reproduce.
Thank you very much for the crash reports!
@ Alex, Emir, Niklas:
Thank you very much for triaging!
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 ...
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
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!
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. :-)
As Roman said before, I "was" using Cinch, so now that I have disabled "Universal Access" the app no longer works :-(
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 18.104.22.168 (Build ID: da8c1e6),
* with LibreOffice 22.214.171.124 (Build ID: 58f22d5),
* with LibreOffice 126.96.36.199 (Build ID: a9a0717),
* with the newest master build for Mac OS X:
LOdev 188.8.131.52.alpha0+ (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 184.108.40.206 (Build-ID: 3fa2330-e49ffd2-90d118b-705e248-051e21c)
* with LibreOffice 220.127.116.11 (Build ID: e29a214)
So this bug is a regression, introduced between the releases of 18.104.22.168 and 22.214.171.124; therefore I add the keyword “regression” and set the Version field to the oldest version which is know to contain the bug (as usual).
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 126.96.36.199+ (Build ID: cfbfa26; pull time: 2012-09-07 10.35.10)
But it is FIRST reproducible with
LOdev 188.8.131.52+ (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 ...
I can confirm that LibreOffice 184.108.40.206 (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 :-)
Changing the component. This is technically not a Calc regression, but is one in the accessibility framework.
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 220.127.116.11 Build ID: e29a214 Writer crash if I try to use "Writing Aids" menu.
Crash report "LibreOffice 18.104.22.168 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...
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 22.214.171.124 Build ID: e29a214 Writer crash if I try to use "Writing Aids"
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 <= 126.96.36.199, you will suffer bug 47368 and its variants; if you use LibreOffice >= 188.8.131.52, 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!
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 :-)
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 ***
VERIFIED as DUPLICATE:
I can no longer reproduce this bug beginning with the 1st available master build after the patch for bug 56937 has been committed:
Version 184.108.40.206.alpha0+ (Build ID: 413d1a932eb4c47510dd05905c1ff467cb186d0)
TinderBox: MacOSX-Intel@1-built_no-moz_on_10.6.8, Branch:master,
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)!
Hi all :-)
I can also confirm that this bug is no longer present in my system with
LOdev Version 220.127.116.11.alpha0+ (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 :-)