Could not reproduce on LO 3.6.3.2 Windows Vista 32 bit

Created attachment 70108 [details]
Screenshot: can't reproduce this bug with LibO 3.6.3.2 on Mac OS X 10.6.8 (Intel)



Thank you very much for your bug report!

However, I can not reproduce it with LibreOffice 3.6.3.2 on Mac OS X 10.6.8 (Intel). If I drag the divider between the tabs section and the horizontal scroll bar, CPU usage goes up to 3% or 4% (according to ‘top’ running in the terminal, see attached screenshot), but not higher, and as soon as I release the mouse (finish dragging), the CPU usage goes down again to about 0%, just as expected.

So there must be some difference between your and my machine/installation which explains the different results, i.e. why you do face this problem while I can’t.

Please help us to find out what makes the difference, i.e. when the problem appears. To do so, please check the following:


1) Can you please try to reset (temporarily) your LibreOffice user profile?
It is possible that the bug is caused by some corrupted setting. To reset your LibreOffice user profile, please:

a) quit LibreOffice, if running;
b) open the folder;
   <your hard drive>/Users/<your user name>/Library/Application Support/
c) there should be a folder called “LibreOffice”, search it;
d) please rename that folder to something else, e.g. “LibreOffice-old”;
e) start LibreOffice again and try if the problem is still reproducible.


2) 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 German:
“Bedienungshilfen”), 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.


3) Do you have installed any window management/user interface utilities/apps/control panels/extensions for MacOS 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 accessibility issues 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 in advance!

Created attachment 70141 [details]
BTT solution

I managed to target the problem, and, as you suggested, it was indeed related to BetterTouchTool.

Adding an exception in BetterTouchTool made the freeze went away.

I also have BetterSnapTool, I didn't have to add any exception there, nor did I have to disable accessibility features.

I'm not sure this makes the issue "resolved", though, more like a "known issue".

Thank you very much for your answer and the results!

> I managed to target the problem, and, as you suggested, it was indeed
> related to BetterTouchTool.
Now we know what has triggered this problem ...

> Adding an exception in BetterTouchTool made the freeze went away.
... and even have a suitable workaround, thank you for that, too!

> I'm not sure this makes the issue "resolved", though, more like a "known
> issue".
Yes, you are right: the problem is not resolved. There is some bug in the LibreOffice code which interacts with the Mac Accessibility API, and this bug gets triggered by BetterTouchTool, because it uses and activates the usage of the Mac Accessibility API.

Therefore I will add this bug to our list of known problems related to the usage of the Mac Accessibility API (bug 55571).

*

The freeze/hang is easily REPRODUCIBLE when BetterTouchTool or RightZoom is installed, therefore I can set the Status of this bug report to NEW.
Reproduced with LibreOffice 3.6.3.2 on Mac OS X 10.6.8 (Intel).

How to reproduce:
1) Either
   a) Install RightZoom, activate it, and include LibreOffice in the list
   of applications it should work with.
   or
   b) Install BetterTouchTool and activate it.
   Hint: it seems that you do not need to make any special settings,
   just click “Yes“ when you are asked if you want to activate Window snapping
   (that prompt appears right at the 1st start of BetterTouchToul).
2) Start LibreOffice (used here: 3.6.3.2).
3) Create a new empty spreadsheet
4) Try to drag the divider at the bottom of the spreadsheet window
   between the tabs section and the horizontal scroll bar.
5) LibO freezes with ca. 100% CPU usage.

I will attach the Mac OS log file created when I had to force quit LibreOffice.

Created attachment 70148 [details]
Mac OS X log file created on force quit of LibO 3.6.3.2, with RightZoom running



This is the Mac OS X log file created when I had to force quit LibreOffice 3.6.3.2, with RightZoom running. The log file includes a simple stack trace (without full symbols, sorry).

This bug is already REPRODUCIBLE in LibreOffice 3.3.0 and 3.4.0.

There is a little difference of symptoms: in these old versions, I have to drag the divider more than once until the freeze/hang occurs; at least, I have to drag the divider once to the right and then once back to the left, a bit into the area of the tabs, to trigger the bug.

So the bug has changed it’s appearance, but nevertheless I would assume that it is still the same bug, and therefore I set the (minimum) Version back to 3.3.0.

*

This bug is still REPRODUCIBLE in the newest master builds, e.g. in
LOdev 4.0.0.0.alpha0+ (Build ID: ed8067; pull time: 2012-11-15 03:54:19)

When I force quit this version right after the freeze has begun,
I get a crash (! a crash *in* the force quit process?! it seems so),
which shows a similar, but slightly different stack backtrace;
I will attach the log file for this kind of crash, too.

Created attachment 70150 [details]
Mac OS X log file created for crash (!) on fast force quit (!) of LOdev 2012-11-15, with RightZoom running

Roman: thank you for the bt.

I noticed this:
comphelper::AccessibleEventNotifier::generateId()
(file comphelper/source/misc/accessibleeventnotifier.cxx)

Here are some lines of the function (:
     55         // Note that the following relies on the fact the elements in the map are traveled with
     56         // ascending keys (aka client ids)
     57         AccessibleEventNotifier::ClientMap &rClients = Clients::get();
     58         for (   ClientMap::const_iterator aLookup = rClients.begin();
     59                 aLookup != rClients.end();
     60                 ++aLookup
     61             )

I didn't understand how "Clients" worked, just saw this:
    struct Clients
        : public rtl::Static< AccessibleEventNotifier::ClientMap, Clients > {};

Could Clients::get() retrieve nothing and so the iterator in "for" loop would fail? (as described here: http://stackoverflow.com/questions/9034749/segmentation-fault-from-std-rb-tree-increment-x-0x1)

Thorsten: one for you?

@ Tor Lillqvist:
Hi Tor,
you have most experience with fixing bugs related to Mac OS X accessibility features. This is another one of these bugs, quite easy to reproduce, and Julien Nabet has already made a suggestion about where exactly in the code the problem is; if his suggestion is true, maybe some simple band-aid could be added to the code which would at least prevent the crash?

Thank you for having a look at this issue!


@ Julien:
Thank you very much for your debugging work!

(In reply to comment #8)
> Could Clients::get() retrieve nothing and so the iterator in "for" loop
> would fail? (as described here:
> http://stackoverflow.com/questions/9034749/segmentation-fault-from-std-rb-
> tree-increment-x-0x1)
> 
Hmmm. generateId looks sane, all callers seem to lock the lclMutex. Might as well be the hang, or not? It is possible that simply the most time is
spent in the function at the bottom of the stack.

Roman: is Valgrind useable on MacOs?
If yes callgrind part could be useful.
Could you launch this?
valgrind --tool=callgrind --simulate-cache=yes --dump-instr=yes ./soffice.bin --splash-pipe=0 <path_to_log_file>
Since it'll be launched from Valgrind, LO will be about 80 times slower so you need to be patient. Once you've got the freeze, wait for some minutes and kill the process
(Log may be quite huge)

(In reply to comment #11)
> Roman: is Valgrind useable on MacOs?
> If yes callgrind part could be useful.
> Could you launch this?
> valgrind --tool=callgrind --simulate-cache=yes --dump-instr=yes
> ./soffice.bin --splash-pipe=0 <path_to_log_file>
> Since it'll be launched from Valgrind, LO will be about 80 times slower so
> you need to be patient. Once you've got the freeze, wait for some minutes
> and kill the process
> (Log may be quite huge)

Hi Julien,

Unfortunately, valgrind is mostly unusable on OSX - even if you install it via the ports mechanism, the developers warn that it doesn't really work very well...

from http://valgrind.org :
"X86/Darwin and AMD64/Darwin (Mac OS X 10.6 and 10.7, with limited support for 10.8)."

from http://www.sealiesoftware.com/valgrind/

 This port is UNSUPPORTED and INCOMPLETE and BUGGY. It may not find bugs in your program, or run your program correctly, or run your program at all. 


So, the situation is not so good there. I tried running it once or twice on some master builds while looking into a few bugs in 3.4 development, but in its current state it is hopeless as a tool for a QAer on Mac.

Alex

Good news! While I can still reproduce this bug (on Mac OS X 10.6.8 (Intel), when RightZoom is installed and active) e.g. in the following master build:

  LOdev 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 it beginning with this master build:

  LOdev 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:3

^This build is the 1st one which includes the patch for bug 56937. My observation suggests that the patch for bug 56937 has also fixed the present bug. This idea is supported by the fact that the stack backtrace for the current bug (e.g. in attachment 70148 [details]) includes the same calls to
  ...
  hitTestRunner(com::sun::star::awt::Point, com::sun::star::uno::Reference
     <com::sun::star::accessibility::XAccessibleContext>)
  ScAccessibleTableBase::getAccessibleChild(long)
  ...
which are, according to
  https://bugs.freedesktop.org/show_bug.cgi?id=57245#c21
a sign that a bug is a duplicate of bug 56937.

Therefore I mark this bug as a duplicate of bug 56937. That bug, and therefore also the present bug, should be fixed in LibreOffice 3.6.5 (which will be released end of January 2013) and 4.0.0, of course.

*** This bug has been marked as a duplicate of bug 56937 ***