Thank you very much for your bug report!

I can not reproduce this for now, but I will try later again (in the moment, I am very busy with a survey of all the old Mac accessibility related bug reports). Therefore:


@ Other bugwranglers:
It would be very nice if someone else could try to reproduce this ...

Some first hints for bugwranglers:
* The stack traces in the three log files are rather similar, therefore I would
  guess that this is actually one bug.
* “UA” means “Universal Access”, Apples accessibility settings in the
  System Preferences. However, from a first look at the stack traces in the
  three log files, I would say that this crash does *not* look like
  closely related to Mac accessibility features. At least it is different
  from all other issues of that kind which I have seen before.
* There is even a good chance that this crash is *not* Mac-specific, but can
  be reproduced on other operating systems ...

One thing I noticed these crashes seem to be more numerous after installing a new version of LO & seem to be less numerous after subsequent launches. When installing new versions of LO on a Mac, I(most if not all) just copy the new .app file to the Applications Folder & launch with no consideration for the currently installed support structure already in place. This may or may not be a problem just an observation since I'm acting as a blind tester. (Please don't make me look at the code!)

Created attachment 67305 [details]
crash dump

Updated to latest nightly .......that's when the program is most susceptible to crashing.

Created attachment 67307 [details]
crash dump

Created attachment 67308 [details]
crash dump

Created attachment 67309 [details]
crash dump

That's enough for now.

@ Phil Reilly:
Thank you very much for all the crash dumps and ideas! If no other Mac bugwrangler can take this, I will look into this issue soon -- right now I’m still at work with some older issues which need to be sorted out. Sorry!

Created attachment 67525 [details]
crash dump

Roll over Beethoven!

Created attachment 67526 [details]
crash dump

Here's the sequence that will cause this 100%:
1. click on Libre office
2. click on preferences
3. click on help fast over & over
4. observe pointer go to bottom of screen & CRASH!

Created attachment 67527 [details]
crash dump

same result from release version 3.6.2!

IF YOU CAN RECREATE IT YOU CAN FIX IT!

These crashes are reproducible on MacBook 3,1 beginning tests on MacBook 4,1

3,1 Lion 3GB RAM................CRASH
4,1 Snow Leopard 2GB RAM........No Crash
4,1 Snow Leopard 4GB RAM........No Crash

3,1 Lion 3GB RAM................CRASH
4,1 Snow Leopard 2GB RAM........No Crash
4,1 Snow Leopard 4GB RAM........No Crash
G4 PPC Leopard  3.6.2 1.5GB RAM.No Crash


Lookin' like LION's the culprit!

3,1 Lion 4GB RAM................CRASH

Thank you for the important hint that this bug might occur only on Mac OS X “Lion”!

Looks like Universal Access needs to be on: Enable access for assistive devices (checked) console gave this msg:

9/22/12 1:18:07.547 PM com.apple.launchd.peruser.501: ([0x0-0x32032].org.libreoffice.script[1519]) Job appears to have crashed: Segmentation fault: 11

Dear bug reporter,

I am sorry for the delay in processing your report! It does not mean that we would not appreciate your help. The problem is just that we currently don’t have much bug wranglers dedicated to Mac OS X, and I (being one of them, and currently the guy for all Mac-accessibility-related crashes and hangs ;-) was busy with an inspection of all the known Mac-accessibility-related bugs (please see attachment 67635 [details] if you are interested). Having finished it, I now turn to your report.

However, as you wrote:
>IF YOU CAN RECREATE IT YOU CAN FIX IT!
This is correct in most cases. But the problem is that I can NOT reproduce it, not even by following your steps given in comment #9 :-(. This might be very well be explained just by your hint (comment #14) that this crash could be specific to Lion (Mac OS X 10.7), but I am still using Snow Leopard (10.6) and need to stay with it for technical reasons. So I will need to ask somebody else who uses Mac OS X >= 10.7 if he can reproduce it; but before I do so, I need to collect as many facts as possible.

Here is a quick summary of your results (for reference):
* Steps to reproduce: see comment #9
* Crash occurs with LibreOffice >= 3.6.2.1
* Crash may be specific to LibreOffice on Mac OS X 10.7 (Lion)
* Crash seems to require that in the System Preferences,
  section “Universal Access”, the option “Enable access for
  assistive devices” is checked.

And here are some of my notes:
* Interesting enough, the log files you have attached are different
  from all others which I can remember for LibreOffice on Mac OS X,
  so could be a special issue.
* Most of your log files are very similar to each other, the exceptions
  are attachment 67133 [details] and attachment 67307 [details] (stack trace different),
  and partially attachment 67305 [details].
* I can find explicit reference to Mac accessibility stuff only in
  attachment 67133 [details], attachment 67305 [details], attachment 67307 [details]
  (all three show calls to sendAccessibilityNotification())
  and attachment 67527 [details] (mentions XAccessibleEventListener).
* Most stack traces show that the crash happens in libobjc.A.dylib,
  after different calls to Apple code, not LibreOffice code;
  the place where we switch from LibreOffice code to Apple’s code
  is always (?)

  16  com.apple.AppKit 0x95885752 -[NSApplication
      nextEventMatchingMask:untilDate:inMode:dequeue:] + 113
  17  libvcllo.dylib   0x01ae99bf AquaSalInstance::Yield(bool, bool) + 1183

* As a non-programmer, I would think this means that we are
  here:
http://opengrok.libreoffice.org/xref/core/vcl/aqua/source/app/salinst.cxx#759
  or here:
http://opengrok.libreoffice.org/xref/core/vcl/aqua/source/app/salinst.cxx#777


But this spare knowledge does not help us much, until we can reproduce this issue. To make this as easy as possible, I need to ask you some more questions:

1) As you mention, you have checked the option “Enable access for
   assistive devices” in the System Preferences, section “Universal
   Access”. Now:
  -- Do you have ANY other of the options in “Universal
   Access” checked, too, e.g. “VoiceOver”, “Zoom”, “Display: White on
   Black” or “Display: Use grayscale”?
  -- Do you have checked “Show Universal Access status in the menu bar”?
  -- Do you have checked any of the options in the other tabs of
   “Universal Access”, i.e. under “Hearing”, “Keyboard”, or
   “Mouse and Trackpad”?
  
2) Do you use any window management utility for Mac OS X, i.e. a little
   application, app or utility which helps to arrange, resize, restore
   the user interface windows, like
   * AquaSnap
   * BetterSnapTool
   * BetterTouchTool
   * Breeze
   * Cinch
   * Divvy
   * DoublePane
   * Flexiglass
   * HyperDock
   * iSnap
   * Moom
   * RightZoom
   * ShiftIt
   * SizeUp
   * SizeWell
   * Spectacle
   * Stay
   * TileWindows
   * WindowTidy
   or something similar?

3) 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 application, or similar?
  -- Do you use any special hardware which could be related to accessibility
   stuff, e.g. a refreshable braille display or braille terminal?
   (Please do not wonder about these questions, I do NOT want to insult you
   by calling you “blind” or so ;-) I just need to ask, because IIRC
   there were some issues related to such software/hardware!)

4) Can you please try if a fresh LibreOffice user profile helps to fix the
   problem, or at least changes anything? To do so, please:
   a) Quit LibreOffice, if running.
   b) Go to 
      <Your main drive>/Users/<Your user folder>/Library/Application Support/
   c) In this folder, there should be a folder called “LibreOffice”,
      which contains most LibreOffice settings (and therefore is called
      the “user profile folder”).
      Just rename this folder so something else, e.g. “LibreOffice-old”.
   d) Start LibreOffice again (the startup should take longer this time,
      because LibreOffice creates a fresh user profile).
   e) Test the issue again. Does this change anything?

Sorry for all these questions, but answers to them could help us to reproduce (and hence to fix) the issue.

Thank you very much in advance!

Ah, there are at least two similar stack traces:

1) in the log cited in bug 52270: “MacSpeech Dictate in French: accented
   letters & frequent crash”. So this is a bug about speach-to-text software,
   maybe that is related (accessibility stuff or similar used)?!

2) in the log cited in bug 49286: “FORMATTING: Conditional formatting
   crashing on OSX 10.6 / LibO 3.5.2.2”.

Both show the same crash in

0   libobjc.A.dylib    0x9446cf87 objc_msgSend + 23

and both the departure from LibreOffice to Apple code in:

14  com.apple.AppKit   0x96c99dd6 -[NSApplication
    nextEventMatchingMask:untilDate:inMode:dequeue:] + 156
15  libvcllo.dylib     0x0190256f AquaSalInstance::Yield(bool, bool) + 1183

So it is very similar that all three issues are related. But the other bugs are not reproducible until now, too ...

@ Phil Reilly:
An additional idea to check. We assumed that this bug may be specific to Lion, but both bug reports mentioned in the previous comments are for Swnow Leopard. So, maybe the fact that you could reproduce the bug only on the MacBook 3,1 Lion 3GB RAM (quoting comment #14):

> 3,1 Lion 3GB RAM................CRASH
> 4,1 Snow Leopard 2GB RAM........No Crash
> 4,1 Snow Leopard 4GB RAM........No Crash
> G4 PPC Leopard  3.6.2 1.5GB RAM.No Crash

could also mean something different. Is there some other difference between the machines -- i.e., is there some “Universal Access” option which is activated *only* on the MacBook 3,1 Lion 3GB RAM which crashes, or is there some system utility/extension, e.g. some window management utility (see comment #18 question 2), installed on that MacBook with Lion which is NOT installed on the other machines? Or any other system/software difference besides the Mac OS version?

Please check this -- if we find some important difference it would help us much!

Looks like this is happening with LazyMouse 2.5 installed which needs UA enabled to work. Tested without UA and cannot recreate. As soon as I activate UA and LazyMouse it is recreate-able. The Snow Leopard machine I tested on does NOT have LazyMouse installed. I'll install LazyMouse on Snow Leopard & test. Looks like LazyMouse is speced till Snow Leopard.

Created attachment 67801 [details]
crash dump

Confirmed on Snow Leopard! LazyMouse in conjunction with UA causes this crash on 10.6 & 10.7.

This crash is NOT reproducible on PPC 10.5 with LazyMouse & UA. LO 3.6.2.1

@ Phil Reilly:

Thank you very much for your additional testing, and for the great results:

> Looks like this is happening with LazyMouse 2.5 installed which needs UA
> enabled to work. Tested without UA and cannot recreate. As soon as I
> activate UA and LazyMouse it is recreate-able.

> Confirmed on Snow Leopard! LazyMouse in conjunction with UA causes this
> crash on 10.6 & 10.7.

*This* is exactly what we needed to know! (So you can skip the rest of my questions from comment #18.)

Now let me try if I can reproduce the crash, too, with LazyMouse ...

And yes, LazyMouse uses Apple’s Accessibility APIs (according http://www.old-jewel.com/lazymouse/documentation/index.html), just as we suspected ...

Old Jewel Software also makes "One Finger Snap" which crashes the TenFourFox application. It to uses the UA features. They should change their name to "OLD WRENCH IN THE WORKS SOFTWARE"!

Bugzilla should have a like button for comments like the previous one!

Thanks! ;-)

Well, I am trying hard to reproduce the issue, but I still have some problems. Of course, I think we are on the right way, but there is some little piece of information missing. Hm ... So an additional question:

Do you have checked any of the additional options in the LazyMouse control panel:
* "Return the cursor to its original position ..." or
* "Play sound" or
* "Show an animation of the cursor moving ..."?

I'm using the free version so "show the animation...." is not on but the others are. See Comment 9 for the procedure. You have to click "Help" fast over & over, I use the track-pad for clicking.

Ah, sorry -- now I got it, finally! ;-)


REPRODUCIBLE on Mac OS X 10.6.8 (Intel), with the preference pane LazyMouse installed and activated, both with
* current master build: LOdev 3.7.0.0.alpha0+, build ID: 3f84462b,
  pull time: 2012-09-30 06:38:06;
* current 3.6 daily build: LibreOffice/LOdev 3.6.3.0+, build ID: 115add8,
  pull time: 2012-10-01 08:43:56

To reproduce, I have used the following steps:
1) Download the free trial version of LazyMouse, available from
       http://www.old-jewel.com/lazymouse/index.html
   (you do not need to pay/register the preference pane to reproduce).
2) Install it by opening the .dmg file and then double-clicking the 
   installer file; follow the onscreen directions.
3) LazyMouse will prompt you to check the option “Enable access for
   assistive devices” in Apple’s “Universal Access” preferences pane;
   please do so.
4) Switch to the (new) LazyMouse preferences pane and start LazyMouse
   by checking the option ”Whenever a new window appears, snap the
   cursor to the: Default button”.
   -> You do not need to change/check any other LazyMouse options;
   in the following I assume that you leave the value of the
   first popup menu as the default: “Default Button”.
5) Rename your LibreOffice user profile folder.
   This step seems necessary: if you skip it, the crash happens
   *sometimes*, but not always.
   (Cf. Phil Reilly’s hint, comment #2:
   “these crashes seem to be more numerous after installing
   a new version of LO & seem to be less numerous after subsequent
   launches.” We can get the same effect by renaming the user profile
   folder.)
6) Start LibreOffice.
   -> The Start Center window appears.
7) Select “LibreOffice > Preferences...” from the menu bar.
   -> The dialog window “Options” appears:
   -> it shows by default the first pane: “LibreOffice > User data”,
   -> AND LazyMouse will move the cursor (pointer) automatically
   over the default button (“OK”).
8) Without moving the cursor at all, just click multiple times
   very fast -- i.e., on the “OK“ button, over which the cursor is.
   -> LibreOffice crashes.

Instead of the preferences/“Options” dialog window, you can also use any (?) other LibreOffice dialog window in which LazyMouse works, i.e. moves the cursor automatically over the default button; e.g. in Writer’s “Format > Paragraph...” dialog window. Just click multiple times fast on the default button.

I have adapted the summary to reflect this most easily reproducible scenario.

This is yet another bug related to LibreOffice code which is triggered when the Mac OS X accessibility API is enabled; LazyMouse relies on the option “Enable access for assistive devices”.

Exactly (!) the same kind of crash is already reproducible on the same machine with LazyMouse and LibreOffice 3.3.0; so this is very probably an old bug, inherited from OpenOffice.org. → Adapted Version field to show (as required) the 1st version in which this bug is known to exist.

Created attachment 67941 [details]
The log file created by Mac OS X 10.6.8 for the LOdev (master) crash



For me, the stack trace in the log file created by Mac OS X 10.6.8 for the LOdev (master) crash looks a little bit different from Phil Reilly’s log files; IMHO the difference is not important, but nevertheless I attach a sample of “my” log files.

All my crashes are 10.7 except the last attachment 67801 [details] is 10.6

(In reply to comment #33)
> All my crashes are 10.7 except the last attachment 67801 [details] is 10.6

A good hint: this explains the little difference in the stack traces -- your last (Mac OS 10.6) attachment looks like my log (Mac OS 10.6), so the stack difference is explained by the OS version.

I have changed the Summary again, to make clear that the fast button clicking is not the only way in which this bug occurs (cf. your comment #0), but just an easily reproducible example.

I will forward this bug to the developers soon, but first I will create a new tracking bug for (remaining) accessibility issues, which makes it easier to keep track of theses bugs.

@ Tor Lillqvist (and Michael Meeks):

I don’t want to waste all your time with these Mac accessibility-related bugs ;-) I just want to inform you about this issue, which I finally managed to reproduce and which seems well worth some debugging, because there are more reports (bug 49286, bug 52270) that might be duplicates, according to the similar stack traces.

Please see comment #30 for a summary of this bug, and for steps to reproduce it.

I’m sorry to say so, but reproducing this issue requires yet another utility: this time, LazyMouse is necessary :-( But it is easy to see why: this bug seems to be related not to window management (like the others), but to mouse cursor animation.

So please look into sometime --
and thank you in advance!

*** Bug 52270 has been marked as a duplicate of this bug. ***

*** Bug 49286 has been marked as a duplicate of this bug. ***

No Progress yet?

Still reproducible in latest nightly.

> No Progress yet?

This is a volunteer project - it is everyone (including you) that has not made any progress on this yet :-) What would really help here - since few of us have Macs - would be to have a stacktrace on a build compiled with symbols: with that we can most likely fix the bug in minutes. Absent it - life is much harder and since I can't test the fix easily it will just consume tons of developer time pointlessly. The "crash dump" data is nice but really rather unhelpful / non-specific.

Thanks !

Michael, if you give me something to test with some instructions, I'll do it.

OpenOffice has the same bug. I opened a bug report there. Maybe they have more resources? Apache OOo Bugzilla – Bug 121449

Phil - you would need to create a build for the Mac with debugging symbols included: http://wiki.documentfoundation.org/Development/How_to_build has some details on that - you'd want to add --enable-symbols to your ./autogen.sh line I guess. Without a good trace with symbols, and without someone with a symbol build reproducing it life is rather difficult.

It'd be a -really- useful contribution if you could get that trace !

Thanks.

Dear Bug Submitter,

This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information.

For more information about our NEEDINFO policy please read the wiki located here: 
https://wiki.documentfoundation.org/QA/FDO/NEEDINFO

If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed.


Thank you for helping us make LibreOffice even better for everyone!


Warm Regards,
QA Team

Latest version 4.1 crashes EASILY by following the procedure in comment #9. You should be able to EASILY reproduce this. The only info you need is at your finger tips!

Looks like its fixed in 4.1.2.3......anybody?

Phil: if you don't reproduce this with last LO version 4.1.4 (and it should be according to your last comment), don't hesitate to put it at RESOLVED/WORKS FOR ME :-)

Somebody fixed it! Who was that masked man?