Created attachment 69841 [details] it is what I call "top input field". Problem description: when starting a "drag and drop" into the "top input field" (the input field common to every cells, just below top menu), libreoffice freezes and you got to kill it. Of course, you loose your current work if not saved. Steps to reproduce: 1. clic on the "top input field", stay in "on press" state. (in other word, start a "drag and drop") 2. release the button anywhere Current behavior: the spinning pinwheel appears. libreoffice freezes. Expected behavior: no spinning pinwheel. Platform : Mac OS X 10.6.8 java version "1.6.0_37"
Can you please add some more details how to reproduce it. I'm unable to do produce a crash or a freeze in a current master build.
Created attachment 70203 [details] top text input during the freeze
Created attachment 70204 [details] sampling of LibreOffice process during the freeze
hello, thanks for trying. I tried again few days ago and I could not reproduce it. I've just tried again a few minutes ago, and it happens again ! :( seems to be quite erratic. FYI, I have a harddrive with 2 bad blocks ... maybe it is the cause ? How to reproduce it ? I run LibreOffice, open a new spreadsheet, do the drag and drop from the "top text input". I add 2 other attachments : - screenshot of the top input field during the freeze - "sampling" of the process LibreOffice during the freeze.
Thank you very much for your bug report -- and especially for the “sampling” of the LibreOffice process during the freeze, because it gives us an important hint about the nature of this freeze! The “sampling”/stack trace contains many references to accessibility stuff: ScAccessibleTableBase, hitTestRunner, accessibility etc. This means that the freeze is related to the use of the Mac OS Accessibility API. We have some long-standing bugs in LibreOffice accessibility stuff which were inherited from OpenOffice and which become visible only when the Mac OS Accessibility API is used (see the comments in bug 55571 etc.) ... and it seems that your report is just about another one of these nasty issues. Therefore, to confirm this observation and to find out what exactly triggers the bug, please check and answer the following questions: 1) Do you have any accesibility features enabled? Apple’s accessibility features like “VoiceOver” or “Enable access for assistive devices”, which get enabled in “System Preferences > Universal Access” (in French: “Préférences Système > Accès universel”), 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 freeze go away, and report the results here. Thank you very much!
Hello thanks for your well documented answer. You're right, I have BetterTouchTool installed (version 0.91). I tried to disable/enable features to narrow the bug down and I was successful. :) When I disable the BetterTouchTool functionality named "Enable window snapping", LibreOffice doesn't freeze. While I'm doing this, "System Preferences > Universal Access > Enable access for assistive devices" is still enabled (as it is required by BetterTouchTool) I'm really glad I could help you and the LibreOffice team. You're doing a fantastic job … keep on going :)
Hello Cédric, (In reply to comment #6) > You're right, I have BetterTouchTool installed (version 0.91). > > I tried to disable/enable features to narrow the bug down and I was > successful. :) > > When I disable the BetterTouchTool functionality named "Enable window > snapping", LibreOffice doesn't freeze. > While I'm doing this, "System Preferences > Universal Access > Enable access > for assistive devices" is still enabled (as it is required by > BetterTouchTool) thank you very much for your answer, and for the sampling file! Both are very helpful. I am sorry for the long delay -- I had to fight with many other bugs and was ill. Now I will finally try to reproduce this issue ...
First, I checked the official terminology; as LibreOffice help tells us, the “top input field” is officially called “Input Line” ;-) So let’s change the Summary accordingly, and also add the hint that this bug is triggered by the BetterTouchTool option “window snapping”. Second, with BetterTouchTool installed and the option “Enable window snapping” checked (thank you for discovering that this option is the necessary thing!), the freeze is easily REPRODUCIBLE both with * LibreOffice 3.4.6.1 (Build ID: a9a0717) * LOdev 4.0.0.0.alpha1+ (Build ID: 6aabe09ac092c51d4b394bde9c7ea0055b952e3; pull time: 2012-11-26 00:28:52) on Mac OS X 10.6.8 (Intel). Setting Status to NEW (= confirmed).
Created attachment 70739 [details] Mac OS X 10.6.8 log file for force quit of LibO 3.6.4.1 due to freeze This is the log file created by Mac OS X for the freeze; the stack backtrace is very similar to the one in Cédric’s log file.
But this bug is NOT reproducible in LibreOffice 3.5.7. So it is a regression. 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 3.6.2.0+ (Build ID: cfbfa26; pull time: 2012-09-07 10.35.10) But it is FIRST reproducible with LOdev 3.6.2.0+ (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: http://cgit.freedesktop.org/libreoffice/core/commit/?id=3234b715b5a6d13ee673b41066eb565706be5ec9 or http://cgit.freedesktop.org/libreoffice/core/commit/?id=9b9d45e35103e6884e0a87c35c07c74899f40614 just like bug 55671 and bug 57245, which seems to have been introduced by one of these patches, too ...
Well - it is deeply frustrating not to be able to debug this - but assumigng the app just hangs - then one of the loops on the stack frames from here are simply not making progress (somehow): 9 -[AquaA11yWrapper accessibilityHitTest:] + 374 (in libvcllo.dylib) [0x1b1cf36] 9 hitTestRunner(com::sun::star::awt::Point, com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessibleContext>) + 683 (in libvcllo.dylib) [0x1b1caeb] 9 hitTestRunner(com::sun::star::awt::Point, com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessibleContext>) + 683 (in libvcllo.dylib) [0x1b1caeb] 9 hitTestRunner(com::sun::star::awt::Point, com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessibleContext>) + 683 (in libvcllo.dylib) [0x1b1caeb] 9 hitTestRunner(com::sun::star::awt::Point, com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessibleContext>) + 683 (in libvcllo.dylib) [0x1b1caeb] 9 hitTestRunner(com::sun::star::awt::Point, com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessibleContext>) + 683 (in libvcllo.dylib) [0x1b1caeb] 9 hitTestRunner(com::sun::star::awt::Point, com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessibleContext>) + 433 (in libvcllo.dylib) [0x1b1c9f1] 9 ScAccessibleTableBase::getAccessibleChild(long) + 131 (in libsclo.dylib) [0x20dc57d3] 9 ScAccessibleSpreadsheet::getAccessibleCellAt(long, long) + 133 (in libsclo.dylib) [0x20dc1df5] 9 ScAccessibleSpreadsheet::GetAccessibleCellAt(long, long) + 179 (in libsclo.dylib) [0x20dbfaa3] 9 ScAccessibleCell::ScAccessibleCell(com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessible> const&, ScTabViewShell*, ScAddress&, long, ScSplitPos, ScAccessibleDocument*) + 160 (in libsclo.dylib) [0x20d7dcf0] 8 accessibility::AccessibleStaticTextBase::AccessibleStaticTextBase(std::auto_ptr<SvxEditSource>) + 72 (in libeditenglo.dylib) [0x219a2e78] 8 accessibility::AccessibleStaticTextBase_Impl::AccessibleStaticTextBase_Impl() + 61 (in libeditenglo.dylib) [0x219a2d6d] 8 accessibility::AccessibleEditableTextPara::AccessibleEditableTextPara(com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessible> const&, accessibility::AccessibleParaManager const*) + 732 (in libeditenglo.dylib) [0x21993f7c] 8 comphelper::AccessibleEventNotifier::registerClient() + 52 (in libcomphelpgcc3.dylib) [0x150e04] 6 comphelper::AccessibleEventNotifier::generateId() + 90 (in libcomphelpgcc3.dylib) [0x1509fa] 6 std::_Rb_tree_increment(std::_Rb_tree_node_base const*) + 16 (in libstdc++.6.dylib) [0x96f63643] 1 comphelper::AccessibleEventNotifier::generateId() + 101 (in libcomphelpgcc3.dylib) [0x150a05] 1 comphelper::AccessibleEventNotifier::generateId() + 99 (in libcomphelpgcc3.dylib) [0x150a03] 1 accessibility::AccessibleStaticTextBase::AccessibleStaticTextBase(std::auto_ptr<SvxEditSource>) + 118 (in libeditenglo.dylib) [0x219a2ea6] 1 accessibility::AccessibleStaticTextBase::SetEditSource(std::auto_ptr<SvxEditSource>) + 42 (in libeditenglo.dylib) [0x219a2b1a] 1 accessibility::AccessibleStaticTextBase_Impl::SetEditSource(std::auto_ptr<SvxEditSource>) + 77 (in libeditenglo.dylib) [0x219a2acd] 1 accessibility::AccessibleEditableTextPara::SetEditSource(SvxEditSourceAdapter*) + 195 (in libeditenglo.dylib) [0x2198abb3] 1 accessibility::AccessibleEditableTextPara::TextChanged() + 36 (in libeditenglo.dylib) [0x21989ec4] 1 comphelper::OCommonAccessibleText::getText() + 25 (in libcomphelpgcc3.dylib) [0x154ba9] 1 accessibility::AccessibleEditableTextPara::implGetText() + 22 (in libeditenglo.dylib) [0x219909b6] 1 accessibility::AccessibleEditableTextPara::GetTextLen() const + 23 (in libeditenglo.dylib) [0x21990177] 1 accessibility::AccessibleEditableTextPara::GetTextForwarder() const + 40 (in libeditenglo.dylib) [0x2198e2f8] 1 SvxEditSourceAdapter::GetTextForwarderAdapter() + 44 (in libeditenglo.dylib) [0x21a9ddbc] 1 ScAccessibleCellTextData::GetTextForwarder() + 1105 (in libsclo.dylib) [0x20dc94e1] 1 EditEngine::CalcTextWidth() + 80 (in libeditenglo.dylib) [0x219b5dd0] 1 ImpEditEngine::CalcTextWidth(unsigned char) + 538 (in libeditenglo.dylib) [0x219e20aa] 1 OutputDevice::Push(unsigned short) + 1 (in libvcllo.dylib) [0x193fbc1]
Wow - so it seems the spreadsheet a11y code is really broken and for some reason we only see it now: uno::Reference< XAccessible > SAL_CALL ScAccessibleTableBase::getAccessibleChild(sal_Int32 nIndex) throw (uno::RuntimeException, lang::IndexOutOfBoundsException) { SolarMutexGuard aGuard; IsObjectValid(); if (nIndex >= getAccessibleChildCount() || nIndex < 0) throw lang::IndexOutOfBoundsException(); sal_Int32 nRow(0); sal_Int32 nColumn(0); sal_Int32 nTemp(maRange.aEnd.Col() - maRange.aStart.Col() + 1); nRow = nIndex / nTemp; nColumn = nIndex % nTemp; return getAccessibleCellAt(nRow, nColumn); } It rather looks like we're iterating over all the cells in a spreadsheet in some horrible way - creating new a11y peers for them - just in order to see if we have a hit test :-) That looks really dumb to me ;-) apparently no cropping only for cells that are visible even is present ;-)
ScAccessibleSpreadsheet::ScAccessibleSpreadsheet( ScAccessibleDocument* pAccDoc, ScTabViewShell* pViewShell, SCTAB nTab, ScSplitPos eSplitPos) : ScAccessibleTableBase (pAccDoc, GetDocument(pViewShell), ScRange(ScAddress(0, 0, nTab),ScAddress(MAXCOL, MAXROW, nTab))), so - this loop could never complete - even if it could do all 10^6 * 10^4 cells. Wow - what a monster. Fundamentally this comes down to a -really- poor set of standards body decisions that try to improve and increase a11y by exposing near infinite sets of data to an accessibility-technology ignorant of the risks, and through a totally inadequate API. Having said that - we screw this up really badly for hit testing - and apparently always have.
Got it - however, I really need someone to test my patch: a plain compile test on Mac would be appreciated, I'm pretty confident in the logic - I'll attach that.
Created attachment 71725 [details] patch - needs compile testing (please) :-)
*** Bug 55671 has been marked as a duplicate of this bug. ***
*** Bug 57245 has been marked as a duplicate of this bug. ***
Michael, if you link some executable code, I'd be happy to do some testing on OS X 10.8.2. Please include a detailed step-by-step on what you want to be tested. is status still new or is this assigned to you now?
we tend not to assign bugs ;-) but yes - I'm taking an interest - IMHO the bug is fixed; as/when someone compile tests it I'll push to master and -4-0 and then a build will pop out of a tinderbox eventually. I don't actually have a mac myself :-)
git am'ing and test compiling... will push if compiles fine
I reproduced the bug, then applied Michael's patch and verified that it helps, yes! Pushed to master.
Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=15aac31ebac23ef745400a8d9c146aef85923c9d fdo#56937 - mac a11y hang related to traversing vast, broken hierarchies. 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.
Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1211bf4682b7e8454d86d5a812df421abf68f662&g=libreoffice-3-6 fdo#56937 - mac a11y hang related to traversing vast, broken hierarchies. It will be available in LibreOffice 3.6.5. 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.
Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a4a467c6e742ea40986287c5f546b0daec295289&g=libreoffice-4-0 fdo#56937 - mac a11y hang related to traversing vast, broken hierarchies. It will be available in LibreOffice 4.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.
*** Bug 58330 has been marked as a duplicate of this bug. ***
VERIFIED as FIXED: while I can still easily reproduce this bug on Mac OS X 10.6.8 (Intel), when the BetterTouchTool option "window snapping" is active, with our 1st beta: Version 4.0.0.0.beta1 (Build ID: 87906242e87d3ddb2ba9827818f2d1416d80cc7) TinderBox: MacOSX TDF Release, Branch:libreoffice-4-0, Time: 2012-12-05_22:13:37 and also e.g. in this master build: Version 4.1.0.0.alpha0+ (Build ID: e43d62fb39e0b6b3e59b22110460d23b6d507b5) TinderBox: MacOSX-Intel@1-built_no-moz_on_10.6.8, Branch:master, Time: 2012-12-06_09:19:57 I can no longer reproduce this bug beginning with the 1st available master build after the patch for this bug has been committed (see comment #22 above): Version 4.1.0.0.alpha0+ (Build ID: 413d1a932eb4c47510dd05905c1ff467cb186d0) TinderBox: MacOSX-Intel@1-built_no-moz_on_10.6.8, Branch:master, Time: 2012-12-19_04:13:37 So this bug is really fixed, and so are its duplicates. @ Michael Meeks: Thank you very much for fixing this nasty issue! This is a big improvement for LibreOffice on Mac OS X, it will help many users, and it will also make easier the life for us QA volunteers (fewer bug reports ;-). Also thanks to Tor Lillqvist for his co-operation!
*** Bug 57071 has been marked as a duplicate of this bug. ***
Very interesting: Bug 57071 (“UI: Freeze when resizing tabs/horizontal scrollbar on OSX with BetterTouchTool or RightZoom running”) is much older than the present one -- bug 57071 is reproducible since LibreOffice 3.3.0, while the present issue first appeared in 3.6.2.1 --, but nevertheless the patch for the present issue seems to have healed bug 57071, too. Why? Probably the roots of the present bug are much older than 3.6.2.1 (which is no surprise, of course!), and it was just “hidden” by another bug (namely bug 47368) until 3.6.2.1.
FYI, I couldn't reproduce the bug with this build : Version 4.1.0.0.alpha0+ (Build ID: 699132c269a6c6d9e815fc582e2e6a106e46923) TinderBox: MacOSX-Intel@1-built_no-moz_on_10.6.8, Branch:master, Time: 2012-12-27_01:05:51 Thanks all for your great work with special mention to Roman and Michael, who surrounded and defeated the a11y hittest monster ;) happy New Year !!
*** Bug 59490 has been marked as a duplicate of this bug. ***