Nightly 3.6.3 9/13/12 crashes occasionally when navigating thru options, menu bar/preferences/about......UA is on but unknown if required to cause crash. Exact sequence is not known. Macbook 3,1 Lion 10.7.5. attachment 67063 [details] attachment 67133 [details] attachment 67134 [details]
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?