Using Writer with Mac OS X causes many health problems. Alternative title: The unstable version of LibreOffice, labeled as "stable" causes unstable minds. After wasting countless hours redoing lost work, I put that time to a much better use and made this video about the bugs: http://www.youtube.com/watch?v=35qjvov2_9k Here's a quick list of the TOP 5 things crashing Writer: 1. Selecting "No Fill" as background color 2. Adding a gray border 3. Adding a 10pt border 4. Adding columns to a footer 5. Selecting "Automatic" font color These are just the TOP 5. All joking aside, I tested this on 3.5.1, Mac OS X (Snow Leopard and Lion). Clean installations with ~/Application Support/LibreOffice removed prior launching. The version is completely unusable as there are hundreds of things that cause a crash. The only workaround I've found is to use an older version (even the 3.4 has similar problems) or just run Ubuntu on a VM.
Now reproduced with: - iMac 27" (2010) with Mac OS X Snow Leopard 10.6.8 - iMac 24" (2009) with Mac OS X Lion 10.7.3 - MacBook Pro (2011) with Mac OS X Lion 10.7.3 - MacBook Pro (2007) with Mac OS X Snow Leopard 10.6.8
On pc Debian x86-64, 3.5 branch updated today (so not exactly 3.5.1), I don't reproduce this problem but perhaps it's mac specific. Just some questions : - do you have any extensions ? If yes, could you disable them and test again ? - On the video, we can see some exceptions, could you copy paste the whole stack trace in a file and attach it here ? Alex Thurgood: isn't there a test you usually propose and which could be useful in this kind of case (disable accessibility or something) ? It's specific MacOs but I don't remember it exactly.
Created attachment 58540 [details] EXC_BAD_ACCESS
Sorry, forgot to include the log before. The only extension I have had on a previous version was the finnish language pack. And not all of the machines that I've tested had that. Other than that, nothing. I happened to have another MacBook Pro for testing where the old installation of Mac OS X had this same problem but after reinstalling the OS, everything worked fine. So there might be something from a previous LibreOffice or OpenOffice installation left that I haven't found. A list of the paths I should just rm -rf to be sure, would be great.
Hmm, I just tested disabling accessibility and so far no crashes.
I add some MAC developers into CC. I have updated the summary to better describe the problem. We have a workaround, so it can't block the release => lowering the severity a bit.
(In reply to comment #6) Hi Petr, > I add some MAC developers into CC. > > I have updated the summary to better describe the problem. > > We have a workaround, so it can't block the release => lowering the severity a > bit. Yes, unfortunately a known problem, and appears to be getting worse (previously it was sporadic, now it seems to be systematic). Something in LO doesn't like Apple's accessibility API, the question is what and where ? It also means that LO for people with disabilities where the accessibility API is useful on Mac is simply not an option. The debug symbols are not provided with the downloadable Mac DMG as far as I know, which makes debugging nigh on impossible for QA. I've never yet been able to build on Mac from master with debug/symbols enabled. Alex
Something that I found out on a clean installation of OS X was, that every time it crashes, it tried to open Java. Might have something to do with that.
(In reply to comment #7) > The debug symbols are not provided with the downloadable Mac DMG as far as I > know, which makes debugging nigh on impossible for QA. I've never yet been able > to build on Mac from master with debug/symbols enabled. I sent a post on dev mailing list about this, see http://nabble.documentfoundation.org/About-LO-Mac-OS-bugs-which-appear-if-accessibility-options-enabled-tp3845211p3845211.html
Tested with LO Daily : LOdev 3.6.0alpha0+ Build ID: 278c53c-19dcfb4-e67b1b (build with symbols) Mac OSX 10.6.8 Snow Leopard Assistive Technology device access option activated (first of the lower tick boxes on the General AT tab) Tests run according to video provided on You Tube link by bug reporter. 32-bit kernel mode: Test 1 Start LO, open New Text Document Right click, context menu Paragraph, Background, pick new Colour from palette Expected result : No crash. Background colour of paragraph changes to new selection Actual result : No crash. Background colour of paragraph changes to new selection Conclusion : not reproducible. Test 2 Start LO, open New Text document Right click, context menu Paragraph, Text Borders, set Width to 10, OK Expected result : No crash. Border thickness line preview shows thicker line Actual result : No crash. Border thickness line preview shows thicker line Conclusion : not reproducible. Test 3 Start LO, open New Text document Click in Header or Footer area, play around with H/F properties dialog Expected result : No crash. Properties of header/footer changed Actual result : No crash. Properties of header/footer changed. Conclusion : not reproducible. Alex
(In reply to comment #10) Redid the tests in 64bit kernel mode - no difference, no crashes with any of the tests. Conclusion : not reproducible. Back to square one. Alex
I also just repeated the tests with VoiceOver activated. Other than the fact that listening to an American voice trying to pronounce French menu entries drove me half-crazy ;-), I was unable to get LO to crash. I even tried the background colour setting for paragraph context menu, clicking wildly over the palette. Hilarious as it was to listen to VoiceOver trying to keep up, there was no crash. So, unfortunately, none of the reporters crashes were reproducible for me on my system. Sorry. Alex
I also tested the master~2012-03-23_05.11.17_LibO-Dev_3.6.0alpha0_MacOS_x86_install_en-US Seems to work just fine with the same machine that had the crashes...
Spoke too soon... "Segmentation fault: 11" when changing border width.
Just by curiosity, i searched for "_AXXMIGCopyElementAtPosition" (present in attached filed "EXC_BAD_ACCESS") and found these links : - http://user.services.openoffice.org/en/forum/viewtopic.php?f=17&t=29261 - http://www.eviware.com/forum/viewtopic.php?t=11634 - http://code.google.com/p/chromium/issues/detail?id=97971 -... (there are others) Perhaps it's normal, I don't know, I just noticed this.
*** Bug 47015 has been marked as a duplicate of this bug. ***
I think with the fdo#47015 we can confirm there's a pb when accessibility is enabled. Q/A or devs guys : Perhaps I'm wrong, if it's the case, don't hesitate to revert the status.
*** Bug 47569 has been marked as a duplicate of this bug. ***
Also tested with : LibreOffice 3.5.1.2 Version ID : dc9775d-05ecbee-0851ad3-1586698-727bf66 Not reproducible on SnowLeopard 10.6.8 with AT activated. Alex
I have lion 10.7.3 with LibreOffice 3.5.1.2 . i found that crash occures on a mac which has first time installed libreoffice and usage of border properties on a system with accessibility enabled . probably when accessibility enabled libreoffice cant get and write system information correctly to “/Users/(**username**)/Library/Application Support/LibreOffice/3/user/registrymodifications.xcu” file. If you run libreoffice and use border functions before without accessibility enabled registrymodifications.xcu file created correctly . after that changing accessibility enable or disable not crash anymore.Also when accessibility disabled and enabled first time run with borber properties usage create different registrymodifications.xcu files with different size. one makes crash other file not. for reproduce to crash quit libreoffice, delete “/Users/(**username**)/Library/Application Support/LibreOffice/3/user/registrymodifications.xcu” file than enable accessibility and open libreoffice again and lastly change any border properties . do same thing with disable accessibility not crash.
(In reply to comment #20) Hi, > for reproduce to crash quit libreoffice, > delete “/Users/(**username**)/Library/Application > Support/LibreOffice/3/user/registrymodifications.xcu” file than enable > accessibility and open libreoffice again and lastly change any border > properties . > do same thing with disable accessibility not crash. Oooh, thanks for that tip, will try it out, but maybe it is just sufficient to rename registrymodifications.xcu so that LO will attempt to recreate it on next startup ? I will try both ways anyway. Alex
accessibility do not effect on creation . but file size are different between accessibility enabled and disabled situation. something added when first time usage of change border properties to this file and accessibility effect on this . (In reply to comment #21) > (In reply to comment #20) > > Hi, > > > for reproduce to crash quit libreoffice, > > delete “/Users/(**username**)/Library/Application > > Support/LibreOffice/3/user/registrymodifications.xcu” file than enable > > accessibility and open libreoffice again and lastly change any border > > properties . > > do same thing with disable accessibility not crash. > > Oooh, thanks for that tip, will try it out, but maybe it is just sufficient to > rename registrymodifications.xcu so that LO will attempt to recreate it on next > startup ? I will try both ways anyway. > > Alex
*** Bug 37913 has been marked as a duplicate of this bug. ***
Toni, a wild guess, but could you try to reproduce it in a master daily build from May 12 or later? just in case it is caused by a certain Mac build system problem with symbol visibility that Tor fixed...
*** Bug 50147 has been marked as a duplicate of this bug. ***
*** Bug 50769 has been marked as a duplicate of this bug. ***
*** Bug 51712 has been marked as a duplicate of this bug. ***
*** Bug 44807 has been marked as a duplicate of this bug. ***
I have nominated this as a "LibreOffice 3.5 most annoying bug" -- see my explanation in bug 37361.
*** Bug 51791 has been marked as a duplicate of this bug. ***
Of course, it'd be fantastic to have a stack-trace with full symbols for this SEGV: 0 libsvtlo.dylib 0x00af5de2 ValueSetAcc::getAccessibleAtPoint(com::sun::star::awt::Point const&) + 146 1 libvcllo.dylib 0x01936c31 hitTestRunner(com::sun::star::awt::Point, com::sun::star::uno::Reference<com::sun::star::accessibility::XAccessibleContext>) + 257 ... uno::Reference< accessibility::XAccessibleContext > SAL_CALL ValueSetAcc::getAccessibleContext() throw (uno::RuntimeException) { ThrowIfDisposed(); return this; } We don't throw - since we get a SEGV; so ThrowIfDisposed must be accessing invalid memory at: address 0x00000000fe000007 - so not related to a NULL ptr I suppose. svtools/source/control/valueimp.hxx shows this inheriting from: class ValueSetAcc : public ::comphelper::OBaseMutex, public ValueSetAccComponentBase typedef ::cppu::PartialWeakComponentImplHelper6<... cppuhelper/inc/cppuhelper/compbase_ex.hxx inc/cppuhelper/interfacecontainer.h:typedef OBroadcastHelperVar< OMultiTypeInterfaceContainerHelper , OMultiTypeInterfaceContainerHelper::keyType > OBroadcastHelper; It -seems- that the 'r' prefix is misleading, and that this is a true member of the class; not a reference/pointer that can go bad; so 'this' must be bad at the ValueSetAcc point.
The amazing thing is that the hitTestRunner code does: if ( rxAccessibleComponent.is() ) { com::sun::star::awt::Point location = rxAccessibleComponent -> getLocationOnScreen(); com::sun::star::awt::Point hitPoint ( point.X - location.X , point.Y - location.Y); Reference < XAccessible > rxAccessible = rxAccessibleComponent -> getAccessibleAtPoint ( hitPoint ); And: awt::Point SAL_CALL ValueSetAcc::getLocationOnScreen() throw (uno::RuntimeException) { ThrowIfDisposed(); const SolarMutexGuard aSolarGuard; const Point aScreenPos( mpParent->OutputToAbsoluteScreenPixel( Point() ) ); awt::Point aRet; aRet.X = aScreenPos.X(); aRet.Y = aScreenPos.Y(); Which must be called immediately beforehand - and is -much- more complex and invasive, fails to crash :-) which is where I'd expect problems to occur if anywhere. So - continuing on the basis that the stack-trace is busted, and that in fact it is getLocationOnScreen that crashes de-referencing mpParent - then ... it is rather unclear to me how, if the ValueSet is destroyed, the ValueSetAcc get it's mpParent pointer cleaned up. I'd expect to have the dispose method do that, but ... no sign of that.
I guess, the invalid internal state is protected by all these IsDisposed calls (fugly but should work). So - I'm lost; prolly the best way to fix it is to get a valgrind trace of a build with debugging symbols; that ~requires a self-built build configured with --enable-symbols I suspect; and of course valgrind on Mac is newish; hopefully with that we'd get somewhere though.
*** Bug 44471 has been marked as a duplicate of this bug. ***
(In reply to comment #32) [...] > const SolarMutexGuard aSolarGuard; [...] Dunno if it is relevant but 'const' here is weird to me... Out of the 5K+ site the use that guard, only a couple hundred use const...
*** Bug 51686 has been marked as a duplicate of this bug. ***
bug#52147 is almost certainly a duplicate. I imagine this is memory corruption in VCL's widget tree etc. I suspect the only good way to find it is using valgrind on Mac (with debugging symbols).
*** Bug 52147 has been marked as a duplicate of this bug. ***
(In reply to comment #35) > (In reply to comment #32) > [...] > > const SolarMutexGuard aSolarGuard; > [...] > > Dunno if it is relevant but 'const' here is weird to me... > Out of the 5K+ site the use that guard, only a couple hundred use const... The "const" there is harmless. Whether or not to include it is a matter of style.
bug#31973 - which is no longer reproducible has an horrible stack-trace: https://bugs.freedesktop.org/attachment.cgi?id=40674 Which makes me nervous; re-enterancy and random method calling during vcl's Window destructor looks scary - though whether that's related is unclear - and the incoming call is on another atk peer than that associated with the window being destructed (it seems - from a fragmentry trace); hmm.
so I built a debug version to get more info... but I still can reproduce. Any hint about what extra stuff need to be installed (I activated Universal Access, even voice to text... no cigar...) maybe this has to do with the fact that I am in en_US locale ? anyone in en_Us able to reproduce ? in which case please detail the setup and maybe extra accessibility widget/programs installed ... If someone that can reproduce is interested I can try to upload a debug build somewhere....
(In reply to comment #41) > Any hint about what extra stuff need to be installed > (I activated Universal Access, even voice to text... no cigar...) Maybe a strange idea, but: you could try to install the one or the other of the window management utilities which rely heavily on MacOS accessibility features and which are known to trigger this (or a very very similar) bug; AFAIK, such utilities are * Moom (see bug 42014) * Cinch (see bug 51791) * RightZoom (see bug 51686) * ShiftIt (see bug 52147) ... The singular bug reports cited above all give some hints which actions seem to crash LibO most often when the specific utility is installed. Hope it helps!
(In reply to comment #41) > Any hint about what extra stuff need to be installed Another idea: most reports about this issue come from users with MacOS X 10.7.x. This may be well a mere coincidence, but it is at least possible that it is easier to trigger this bug on 10.7.x than on 10.6.x ... (I’m on 10.6.8, and I could never manage to reproduce this bug).
(In reply to comment #41) > Any hint about what extra stuff need to be installed [...] > If someone that can reproduce is interested I can try to upload a debug build > somewhere.... Sorry for all these posts, but I keep learning ;-): I have finally managed to reproduce bug 51686 -- after installing RightZoom, I can crash LibO 3.5.5.3 reliably by following the description in bug 51686. Caution: I can’t swear that bug 51686 is identical with this (present) issue, but at least the crash log looks promisingly: Thread 0 which crashed references ... ValueSetAcc::getAccessibleAtPoint() ... com::sun::star::accessibility::XAccessibleContext ... AquaA11yWrapper accessibilityHitTest: ... NSApplication(NSApplicationAccessibility) accessibilityHitTest So please either try this yourself (just install RightZoom, activate it, and add LibO to the list of allowed applications -- and LibO crashes like a charm ;-), or upload your debug build and give me a link.
I confirm the RightZoom does the trick. I was never able to reproduce so far.. I installed RightZoom and activated it for libreoffice (in fact for everything) started lo 3.6 and started the scenrion descriped in msg# It did not fail quite like described be pretty soon it dumped Process: soffice [24105] Path: /Volumes/Raid0/g_core/solver/unxmacxi.pro/installation/opt/LibreOffice.app/Contents/MacOS/soffice Identifier: org.libreoffice.script Version: 3.6.0.2 (???) Code Type: X86 (Native) Parent Process: launchd [239] Date/Time: 2012-07-22 06:52:33.399 -0500 OS Version: Mac OS X 10.6.8 (10K549) Report Version: 6 Interval Since Last Report: 313372 sec Crashes Since Last Report: 605284 Per-App Interval Since Last Report: 301 sec Per-App Crashes Since Last Report: 1 Anonymous UUID: 80DA7628-1FAC-4CFF-BDEB-C2B268BC8FB5 Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 ??? 0000000000 0 + 0 1 libsvxlo.dylib 0x340d63c6 svx::a11y::AccFrameSelector::LinkStubWindowEventListener(void*, void*) + 24 (AccessibleFrameSelector.cxx:645) 2 libsofficeapp.dylib 0x000feab9 Link::Call(void*) const + 39 (link.hxx:143) 3 libvcllo.dylib 0x033040f4 VclEventListeners::Call(VclSimpleEvent*) const + 160 (vclevent.cxx:73) 4 libvcllo.dylib 0x03682fc5 Window::CallEventListeners(unsigned long, void*) + 155 (window.cxx:5186) 5 libvcllo.dylib 0x036830c7 Window::ImplCallEventListeners(unsigned long, void*) + 31 (window.cxx:5168) 6 libvcllo.dylib 0x0369e648 Window::~Window() + 264 (window.cxx:4210) 7 libvcllo.dylib 0x0332b85a Control::~Control() + 98 (ctrl.cxx:91) 8 libsvxlo.dylib 0x341a2a45 svx::FrameSelector::~FrameSelector() + 61 (frmsel.cxx:789) 9 libcuilo.dylib 0x3af6bc19 SvxBorderTabPage::~SvxBorderTabPage() + 2277 (border.cxx:333) 10 libsfxlo.dylib 0x00cf3302 SfxTabDialog::~SfxTabDialog() + 1096 (tabdlg.cxx:495) 11 libswuilo.dylib 0x3a82ddc2 SwParaDlg::~SwParaDlg() + 38 (pardlg.cxx:168) 12 libswuilo.dylib 0x3a877cee AbstractTabDialog_Impl::~AbstractTabDialog_Impl() + 62 (swdlgfact.cxx:120) 13 libswlo.dylib 0x322e00ed SwTextShell::Execute(SfxRequest&) + 17593 (textsh1.cxx:1051) 14 libswlo.dylib 0x322d0fe8 SfxStubSwTextShellExecute(SfxShell*, SfxRequest&) + 24 (swslots.hxx:2375) 15 libsfxlo.dylib 0x00c670e0 SfxShell::CallExec(void (*)(SfxShell*, SfxRequest&), SfxRequest&) + 24 (shell.hxx:199) 16 libsfxlo.dylib 0x00c50cc2 SfxDispatcher::Call_Impl(SfxShell&, SfxSlot const&, SfxRequest&, unsigned char) + 1070 (dispatch.cxx:263) 17 libsfxlo.dylib 0x00c53cf1 SfxDispatcher::PostMsgHandler(SfxRequest*) + 267 (dispatch.cxx:1245) 18 libsfxlo.dylib 0x00c53df8 SfxDispatcher::LinkStubPostMsgHandler(void*, void*) + 24 (dispatch.cxx:1216) 19 libsofficeapp.dylib 0x000feab9 Link::Call(void*) const + 39 (link.hxx:143) 20 libsfxlo.dylib 0x00e65731 GenLink::Call(void*) + 53 (genlink.hxx:54) 21 libsfxlo.dylib 0x00e6568f SfxHintPoster::Event(SfxHint*) + 27 (hintpost.cxx:72) 22 libsfxlo.dylib 0x00e65759 SfxHintPoster::DoEvent_Impl(SfxHint*) + 31 (hintpost.cxx:62) 23 libsfxlo.dylib 0x00e65672 SfxHintPoster::LinkStubDoEvent_Impl(void*, void*) + 24 (hintpost.cxx:65) 24 libsofficeapp.dylib 0x000feab9 Link::Call(void*) const + 39 (link.hxx:143) 25 libvcllo.dylib 0x036aa2be ImplHandleUserEvent(ImplSVEvent*) + 220 (winproc.cxx:2003) 26 libvcllo.dylib 0x036acfa3 ImplWindowFrameProc(Window*, SalFrame*, unsigned short, void const*) + 1871 (winproc.cxx:2576) 27 libvcllo.dylib 0x036bdf39 SalFrame::CallCallback(unsigned short, void const*) const + 63 (salframe.hxx:281) 28 libvcllo.dylib 0x036bd7fb AquaSalInstance::Yield(bool, bool) + 335 (salinst.cxx:736) 29 libvcllo.dylib 0x032ef653 ImplYield(bool, bool) + 177 (svapp.cxx:452) 30 libvcllo.dylib 0x032ebcd0 Application::Yield(bool) + 32 (svapp.cxx:486) 31 libvcllo.dylib 0x032ebcf8 Application::Execute() + 38 (svapp.cxx:429) 32 libsofficeapp.dylib 0x000fd8fa desktop::Desktop::Main() + 8340 (app.cxx:1823) 33 libvcllo.dylib 0x032f7697 ImplSVMain() + 87 (svmain.cxx:183) 34 libvcllo.dylib 0x036bc82b AquaSalInstance::handleAppDefinedEvent(NSEvent*) + 219 (salinst.cxx:606) 35 libvcllo.dylib 0x03718882 -[VCL_NSApplication sendEvent:] + 64 (vclnsapp.mm:217) 36 com.apple.AppKit 0x93edc253 -[NSApplication run] + 917 37 com.apple.AppKit 0x93ed4289 NSApplicationMain + 574 38 libvcllo.dylib 0x036ba459 ImplSVMainHook(int*) + 375 (salinst.cxx:243) 39 libvcllo.dylib 0x032f77c7 SVMain() + 17 (svmain.cxx:217) 40 libsofficeapp.dylib 0x0012c711 soffice_main + 293 (sofficemain.cxx:77) 41 org.libreoffice.script 0x00001f26 sal_main + 11 (main.c:35) 42 org.libreoffice.script 0x00001f0e main + 29 (main.c:33) 43 org.libreoffice.script 0x0000187a _start + 216 44 org.libreoffice.script 0x000017a1 start + 41 Thread 1: 0 libSystem.B.dylib 0x9a016b5a semaphore_timedwait_signal_trap + 10 1 libSystem.B.dylib 0x9a0446e1 _pthread_cond_wait + 1066 2 libSystem.B.dylib 0x9a08d26c pthread_cond_timedwait + 47 3 libuno_sal.dylib.3 0x0001d881 rtl_cache_wsupdate_wait(unsigned int) + 99 (alloc_cache.cxx:1384) 4 libuno_sal.dylib.3 0x0001da47 rtl_cache_wsupdate_all(void*) + 51 (alloc_cache.cxx:1523) 5 libSystem.B.dylib 0x9a044259 _pthread_start + 345 6 libSystem.B.dylib 0x9a0440de thread_start + 34 Thread 2: Dispatch queue: com.apple.libdispatch-manager 0 libSystem.B.dylib 0x9a03d382 kevent + 10 1 libSystem.B.dylib 0x9a03da9c _dispatch_mgr_invoke + 215 2 libSystem.B.dylib 0x9a03cf59 _dispatch_queue_invoke + 163 3 libSystem.B.dylib 0x9a03ccfe _dispatch_worker_thread2 + 240 4 libSystem.B.dylib 0x9a03c781 _pthread_wqthread + 390 5 libSystem.B.dylib 0x9a03c5c6 start_wqthread + 30 Thread 3: 0 libSystem.B.dylib 0x9a0de096 accept$NOCANCEL$UNIX2003 + 10 1 libSystem.B.dylib 0x9a0dceff accept + 32 2 libuno_sal.dylib.3 0x00008a42 osl_acceptPipe + 182 (pipe.c:467) 3 libsofficeapp.dylib 0x0012a178 osl::Pipe::accept(osl::StreamPipe&) + 20 (pipe.hxx:141) 4 libsofficeapp.dylib 0x00127f48 desktop::OfficeIPCThread::execute() + 42 (officeipcthread.cxx:646) 5 libuno_salhelpergcc3.dylib.3 0x00b77b35 salhelper::Thread::run() + 39 (thread.cxx:60) 6 libuno_salhelpergcc3.dylib.3 0x00b77eca threadFunc + 30 (thread.hxx:197) 7 libuno_sal.dylib.3 0x000122a1 osl_thread_start_Impl + 268 (thread.c:271) 8 libSystem.B.dylib 0x9a044259 _pthread_start + 345 9 libSystem.B.dylib 0x9a0440de thread_start + 34 Thread 4: 0 libSystem.B.dylib 0x9a016b5a semaphore_timedwait_signal_trap + 10 1 libSystem.B.dylib 0x9a0446e1 _pthread_cond_wait + 1066 2 libSystem.B.dylib 0x9a08d26c pthread_cond_timedwait + 47 3 libuno_sal.dylib.3 0x0004848e osl_waitCondition + 656 (conditn.cxx:264) 4 configmgr.uno.dylib 0x1c53ee16 osl::Condition::wait(TimeValue const*) + 26 (conditn.hxx:85) 5 configmgr.uno.dylib 0x1c538196 configmgr::Components::WriteThread::execute() + 52 (components.cxx:191) 6 libuno_salhelpergcc3.dylib.3 0x00b77b35 salhelper::Thread::run() + 39 (thread.cxx:60) 7 libuno_salhelpergcc3.dylib.3 0x00b77eca threadFunc + 30 (thread.hxx:197) 8 libuno_sal.dylib.3 0x000122a1 osl_thread_start_Impl + 268 (thread.c:271) 9 libSystem.B.dylib 0x9a044259 _pthread_start + 345 10 libSystem.B.dylib 0x9a0440de thread_start + 34 Thread 0 crashed with X86 Thread State (32-bit): eax: 0x1db26508 ebx: 0x340d62f0 ecx: 0xbfffdffc edx: 0x00000000 edi: 0x00000000 esi: 0x03303a0a ebp: 0xbfffdf08 esp: 0xbfffdecc ss: 0x0000001f efl: 0x00210206 eip: 0x00000000 cs: 0x00000017 ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037 cr2: 0x00000000
(In reply to comment #45) > I confirm the RightZoom does the trick. [...] Good news! > pretty soon it dumped [...] Just curious: What did you do to get this crash? My crash log (attachment 64499 [details]: just an ordinary MacOS X log, not from a debug build) looks different and contains more references to code points with 'accessibility' in their name. I generated this log via opening an .ods file with some cells with a background color, selecting one of these cells and then selecting "No Fill" from the palette under the Background Fill toolbar button. This crash is 100% reproducible for me with LibO 3.5.5.3. Can you try this, too? I wonder how the dump from your debug build will look ... (I can send you the .ods file I used if it is important.)
(In reply to comment #46) > (In reply to comment #45) > > I confirm the RightZoom does the trick. [...] > > Good news! > > > pretty soon it dumped [...] > > Just curious: What did you do to get this crash? My crash log (attachment > 64499 [details]: just an ordinary MacOS X log, not from a debug build) looks different > and contains more references to code points with 'accessibility' in their name. > I generated this log via opening an .ods file with some cells with a background > color, selecting one of these cells and then selecting "No Fill" from the > palette under the Background Fill toolbar button. I created a new empty writer document, right click paragrph.... then clicked on nofill it did not blow up immediatly, so I clicked some other color then nofill then close.. the dialog closed but the app frooze at that point... I even had the time to do a 'sample' via activity monitor... eventualy I got the 'crash dialog with the backtrace attached above. the 'sample' showed the same backtrace
*** Bug 47275 has been marked as a duplicate of this bug. ***
Due to the DUPs "Bug 52342 - AutoFilter CRASH", "Bug 47275 - Autofilter CRASH" it's now more or less "All LibO apps."
Created attachment 64540 [details] prototype patch for testing ... Clearly the problem with copying the listeners list is the re-enterancy hazard from Call is not well protected against. Well - this, and also that the -whole- VCL window lifecycle is a real train-crash with these listeners for object death instead of hard, properly tracked reference counts.
Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d5bbd67f675be962e294c24ee8b6ecccd1f341e8 fdo#47368 - fix one potential re-enterancy hazard around even emission
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=222b7032153cfd3a6f5e12e2fc855ccabc2ea769&g=libreoffice-3-6 fdo#47368 - fix one potential re-enterancy hazard around even emission It will be available in LibreOffice 3.6.1.
(In reply to comment #45) > It did not fail quite like described be pretty soon it dumped (In reply to comment #47) > I created a new empty writer document, right click paragrph.... then clicked > on nofill it did not blow up immediatly, so I clicked some other color > then nofill then close.. the dialog closed but the app frooze at that point... I wondered why it was a bit difficult for Norbert to reproduce this bug even with RightZoom installed ("It did not fail quite like described"); for me, installing RightZoom made crash LibreOffice on selecting nofill for background color immediately. And Norbert's crash log (comment #45) looks quite different from my own one (attachment 64499 [details]) -- it does not only contain additional debugging info, but mentions different codepoints, and far less Accessibility stuff as my one. Why? Finally I got it: I tested bug 51686 and this bug with LibO 3.5.5.3, but Norbert's debug build is a debug version of LibO 3.6.0.2. Now LibO 3.6.0.2 (or the whole 3.6.x branch) suffers from bug 51943: "Text color setting is broken", which makes exactly difficult what is necessary to reproduce this bug with RightZoom: setting the text background color does not work anymore on MacOS. Norbert did not know this, I should have known when I suggested to install RightZoom (comment #44), but I just thought about 3.5.x in this issue and forgot totally about bug 51943 ... This may explain the difference of the log files. I even fear (but I don't know) that bug 51943 currently "covers" or "hides" bug 51686 and therefore makes it difficult to generate useful debugging info for this present bug by the way I suggested. Maybe because of that Norbert's crash log (comment #45) has more to do with bug 51943 than with the present accessibility issue? If so, then we need either to fix bug 51943 first and then make another debug build, or to find other ways to get the debug build crash with the accessibility issue ...
(In reply to comment #53) > (In reply to comment #45) > > It did not fail quite like described be pretty soon it dumped > > (In reply to comment #47) > > I wondered why it was a bit difficult for Norbert to reproduce this bug even > with RightZoom installed ("It did not fail quite like described"); for me, > installing RightZoom made crash LibreOffice on selecting nofill for background > color immediately. actually, today, while trying to verify Michael's patch, I could not reproduce the crash anymore, even with the same binary I tested with yesterday :-(
(In reply to comment #54) > actually, today, while trying to verify Michael's patch, I could not reproduce > the crash anymore, even with the same binary I tested with yesterday :-( I can’t, too: while I can reproduce the crash so easily with LibO 3.5.5.3, I can’t reproduce it with your (Norbert’s) debug build -- I have tried for the 3rd time now. This is why I fear that bug 51943 currently "covers" or "hides" our accesibility issue, at least when testing with RightZoom and selecting a text/background color. So what to do now? Can we create a debug build of 3.5.5 (then I hope I will be able to reproduce the issue for sure)? At the moment, I'm searching all the other duplicates of this present bug and trying to get your (Norbert’s) 3.6.0.2 debug build to crash ... ;-)
Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-3-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=59205e8d8136eeb5a2648b2fb39d747ebfdb19de&g=libreoffice-3-6-0 fdo#47368 - fix one potential re-enterancy hazard around even emission It will be available already in LibreOffice 3.6.0.
Thanks to Norbert’s debug version of LibreOffice 3.6.0.2+, I spent several hours trying to reproduce all the different kinds of crashes which are mentioned in this bug report and in all its duplicates. For this I used MacOS X 10.6.8 (Intel) with "Enable access for assistive devices" checked in the System Preferences and RightZoom running (cf. comment 44). Now here is a quick overview of my results -- which, I fear, are not as helpful as I had expected. But only the developers can tell. (1) and (2) I can NOT reproduce two kinds of crashes specific to Impress (bug 47569 and bug 50147). What regards the latter one (sorting slides), this could be explained by bug 51023, which currently makes sorting slides in LibO 3.6.x on MacOS mostly impossible, and therefore may also "hide" bug 50147. (3) I can reproduce the crash in the LibreOffice Preferences (application "Options") window (bug 44807, bug 52147, and probably bug 37913). See my comment in bug 52147. For this crash, I got two slightly different kinds of crash logs, see attachment 64599 [details] and attachment 64600 [details]. Good news, I hope: both contain explicte references to Accessibility stuff, e.g. XAccessibleContext, XAccessibleComponent, XAccessibleAction. So it may be helpful to look into these log files. I can investigate more, if you want and tell me what to do ... (4) As said above (comment #55), I can NOT reproduce the crash which occurs on setting character color and character background color (bug 51686 etc.), and I think -- but I may be totally wrong -- that this has to do with the new bug 51943. See comment #55, again. (5) and (6) But I can reproduce a crash with two similar color-setting related actions (cf. comment #0 in this report): When I open Writer and add a background color to a paragraph (via Format > Paragraph) or to a table (Via Table > Table properties...), LibO crashes. NB: It may be necessary to click forth and back through the different tabs of the "Paragraph" or "Table Properties" dialog before to get the crash. On both crashes, I get nearly identical log files -- see attachment 64594 [details], and my comments in bug 51686. Both log files are also more or less identical with Norbert’s log file, cited here in comment #45. (7), (8), (9) Many bug reports speak about crashes when adding a border to a cell in Calc or to a paragraph in Writer, or when changing border properties -- see this present report (comment #0), and bug 50467 and bug 51791. I can reproduce this crash in at least three ways: in Calc, when I add a border to a cell (see attachment 64555 [details]); in Writer, when I add a border to a paragraph (see attachment 64590 [details]) or when I change the border width of a table (see attachment 64592 [details]). Cf. my comments in bug 50467. All three log files are very similar, and they are more or les identical to attachment 64594 [details] from point (5) above and to Norbert’s log file (comment #45). All these log files don’t contain explicte references to Accessibility stuff (but only the developers can really judge this). So these crashes seem to have all the same technical background. (10) I can reproduce a freeze or crash related to auto-filter in Calc -- this is bug 47275 and bug 52342. See my comments in bug 47275. The log file for the freeze (attachment 47275 [details]) could be especially interesting, because it contains explicte references to Accessibility stuff. The crash log (attachment 47275 [details]) may be less interesting (no Accessibility stuff?), but only our developers can judge this. That’s it -- my results of several hours spent with making LibreOffice crash, a rather destructive pastime ;-) Hope it helps a bit ...
Sorry, tired by too much testing done: Section (10) of the previous comment should read (attachment IDs were wrong!): (10) I can reproduce a freeze or crash related to auto-filter in Calc -- this is bug 47275 and bug 52342. See my comments in bug 47275. The log file for the freeze (attachment 64596 [details]) could be especially interesting, because it contains explicte references to Accessibility stuff. The crash log (attachment 64597 [details]) may be less interesting (no Accessibility stuff?), but only our developers can judge this. And I can't tell what was the difference, i.e. why LibO froze the 1st time and crashes the 2nd time.
Hi Roman; so - the fix we pushed potentially catches a ton of segv's that have: VclEventListeners::Call(VclSimpleEvent*) const in the last ~5 or so stack-frames; of course - perhaps it doesn't fix the issue - there could clearly be other badness here; but perhaps it does. It'd be great to test the latest snapshot from Norbert's tinderbox that eg. I hope that: http://dev-builds.libreoffice.org/daily/MacOSX-Intel@1-built_no-moz_on_10.6.8/master/current/ makes it ~impossible to reproduce the bulk of these a11y problems :-) if not, we need to think again of course. If so - we need to back-port this to 3.5 and close it I guess. It'd be really lovely to have some testing of that (if possible !). Thanks :-)
(In reply to comment #59) > Hi Roman; so - the fix we pushed potentially catches a ton of segv's that have: > > VclEventListeners::Call(VclSimpleEvent*) const > > in the last ~5 or so stack-frames; of course - perhaps it doesn't fix the issue > - there could clearly be other badness here; but perhaps it does. I would expect the patch to fix issues (5) to (9) from my list in comment #57, and maybe issue (10) -- VclEventListeners::Call is in the crash log (attachment 64597 [details]), but not in the log file for the freeze (attachment 64596 [details]). But at least issue (3) looks entirely different, so please take a special look at this one. > It'd be great to test the latest snapshot from Norbert's tinderbox I will do so and report my findings.
Created attachment 64623 [details] Crash log - LOdev 2012-07-24 - Writer, add bkg color to paragraph (In reply to comment #59) > It'd be great > to test the latest snapshot from Norbert's tinderbox that eg. I hope that: > > http://dev-builds.libreoffice.org/daily/MacOSX-Intel@1-built_no-moz_on_10.6.8/master/current/ > > makes it ~impossible to reproduce the bulk of these a11y problems :-) if not, > we need to think again of course. I fear "we need to think again". I have tested again with the latest master build, i.e. with LOdev 3.7.0.0.alpha0+ (Build ID: 7727f93, installation file: master~2012-07-24_01.17.17_LibO-Dev_3.7.0.0.alpha0_MacOS_x86_install_en-US.dmg), and RightZoom running, and can still reproduce the crashes listed in my comment #57 ... There is only a slight difference in the log files for the crashes. I will not post them all, but attached you find the new log file for case (5) from my distinction in comment #57, i.e. for adding a background color to a paragraph in Writer. Please compare this with the old attachment 64594 [details]. The first lines of the listing for thread 0 are different ... I can post more log files created on crashes with the new master built, of course, just tell me ;-)
> I fear "we need to think again" Ok - then we badly need that valgrind trace - Norbert ? :-) ...
An observation which *could* be helpful in finding the bug: https://bugs.freedesktop.org/show_bug.cgi?id=51686#c9 (Bug 51943 is fixed now, the color pulldown palettes work again, but nevertheless bug 51943 does not return, therefore Winfried’s and/or Thorsten’s changes in the code for the color pulldown palettes seem to have eliminated the accessibility-related crashes by the way ... could this give a clue about where the bug is?)
(In reply to comment #63) > ... seem to have eliminated the accessibility-related > crashes by the way ... could this give a clue about where > the bug is?) > Depending on which version you tested - Michael's fix is in recent -3-6, master, and -3-6-0 as well, I'd be more inclined to attribute fixing this to him therefore. ;)
if there's good feedback for the patch (and yes it's hard to see how the color selector change could fix any mac a11y problem) I'll cherry-pick it to libreoffice-3-5 ...
(In reply to comment #64) > Depending on which version you tested I tested the latest master build (LOdev 3.7.0.0.alpha0+, Build ID: c549e1e, installation file: master~2012-07-25_02.21.07_LibO-Dev_3.7.0.0.alpha0_MacOS_x86_install_en-US.dmg) with US English langpack installed. > I'd be more inclined to attribute fixing this to > him therefore. ;) I did not want at all to dispute which patch did the job. But it is interesting that from all the ways to make LibreOffice crash which I have listed in comment #57, only no. (4) seems no longer reproducible. The ways (5) to (9), which all produce crash logs similar to Norbert’s one (comment #45), and towards which Michael’s patch seems to be directed (because they all involve VclEventListeners::Call() in the topmost stack-frames), are all still reproducible for me with the current master build. This is why I was under the impression that not Michael’s fix, but some change in the color selector code did the job -- because even cell/paragraph background color selection is fixed only when done via the color pulldown palettes (case (4)), but still causes crashes when done via menu and Cell/Paragraph properties window (case (5)/(6)). But I don’t want to dispute ;-) I’m only a simple-minded QA volunteer. I just want to point out that there remains much to do; besides (5) to (9), also case (3) is still reproducible, and I can’t guarantee that (1) and (2) are really fixed -- I can’t reproduce them, of course, but maybe this needs some special circumstances (e.g. MacOS X 10.7.x, or running another window management utility, etc.). (In reply to comment #65) > if there's good feedback for the patch (and yes it's hard to see how the color > selector change could fix any mac a11y problem) I'll cherry-pick it to > libreoffice-3-5 ... Please do so. Then we can see if color selection via the color pulldown palettes will be fixed in 3.5.x, too (this would mean that Michael’s patch did the job, and it will receive all my applause then, as appropriate!), or not (then the 3.6 changes in the code for the color pulldown palettes would be the reason).
Michael Meeks committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=68a81bb592f269712372173abcc50483dd556d56&g=libreoffice-3-5 fdo#47368 - fix one potential re-enterancy hazard around even emission It will be available in LibreOffice 3.5.6.
(In reply to comment #66) > (In reply to comment #65) > > if there's good feedback for the patch (and yes it's hard to see how the > > color selector change could fix any mac a11y problem) I'll cherry-pick > > it to libreoffice-3-5 ... > > Please do so. Then we can see if color selection via the color pulldown > palettes will be fixed in 3.5.x, too (this would mean that Michael’s patch did > the job [...]), or not I have tested again with LibreOffice 3.5.6.1, which contains the patch mentioned above (see comment #67), and I am sorry to say that selecting Font Color "Automatic" or Highlighting Color "No Fill" or (paragraph) Background color "No Fill" from the color pulldown palettes or from the "Character" and "Paragraph" dialog windows still crashes LibreOffice 3.5.6.1. Please see the crash logs: * attachment 65116 [details] * attachment 65117 [details] * attachment 65118 [details] All three log files are very similar. At the beginning of the files I have noted down the steps necessary to reproduce the crash. Also, all of the other ways to crash LibreOffice enumerated by me in comment #57 still work (i.e., crash) with LibreOffice 3.5.6.1. What this means should be judged by the developers, but I fear that it is still true what Michael Meeks stated in comment #62.
*** Bug 53221 has been marked as a duplicate of this bug. ***
*** Bug 50710 has been marked as a duplicate of this bug. ***
*** Bug 50467 has been marked as a duplicate of this bug. ***
*** Bug 42866 has been marked as a duplicate of this bug. ***
No "See also" for bug 44807 necessary, if bug 44807 is already marked as a duplicate of the present bug.
Very interesting: see Alex Thurgood's comments in bug 49576, "Accessibility - MAC AT accessibility problems". Does this help anything to fix the present issue, or at least to understand it better?
*** Bug 33359 has been marked as a duplicate of this bug. ***
Some updates about the importance of this bug: (1) According to https://bugs.freedesktop.org/duplicates.cgi?sortby=count&reverse=1&bug_id=46074%2C46901%2C36263%2C36677%2C46071%2C45081%2C44664%2C37488%2C40298%2C50552%2C50139%2C40571%2C46155%2C44720%2C39007%2C36301%2C49853%2C47044%2C46230%2C43989%2C37044%2C37024%2C34814%2C33463%2C33229%2C32664%2C50651%2C38244%2C37559%2C36496%2C36336%2C35972%2C34617%2C33114%2C32826%2C31716%2C31023%2C47963%2C47368%2C46687%2C45117%2C45020%2C44742%2C43869%2C42169%2C40261%2C39659%2C39093%2C37913%2C37654&sortvisible=0&product=LibreOffice&maxrows=100&changedsince=7 this is the open bug with most duplicates now. Congratulations to the winner;-) And there are more bugs which are most probably duplicates of this one, too (e.g., bug 53240 and bug 52014), so additional duplicates are coming ... (2) This bug has real relevance for many people, because our workaround: to disable MacOS accessibility features completely, is not a suitable workaround for many people with this or that kind of physical impairment. Some days ago, Vincenzo (info@titengodocchio.it) wrote to the QA list: "Let's take, for instance, the mac os x version of LO: unfortunately it contains tons of accessibility bugs that make impossible to use it for a blind user [...] Just my opinion; maybe I am late, but I decided to share the opinion from my blind-user waiting for an accessible mac os x version of lo perspective..." So we need to stop this discriminating bug -- finally. (3) If no one has got a new idea about how to fix this issue, I want to quote Michael Meeks’s comment 62, because this is probably the hard way we need to go now (now, or tomorrow, but not some years in the future ;-): > > I fear "we need to think again" > > Ok - then we badly need that valgrind trace - Norbert ? :-) ... Thank you all! (For the record: I change the Importance field, not because I would believe that this would help anything to fix the issue, but only because QA is discussing about sorting bugs by priority, and therefore we need to get the Importance fields right. Additionally, I put the Whiteboard information into "(...)", to mark this information as a comment, because the issue was not fixed in these releases.)
(In reply to comment #76) > this is the open bug with most duplicates now. Congratulations to the winner;-) So, how many internets did I win? > (2) This bug has real relevance for many people, because our workaround: to > disable MacOS accessibility features completely, is not a suitable workaround > for many people with this or that kind of physical impairment. Some days ago, > Vincenzo (info@titengodocchio.it) wrote to the QA list: > > "Let's take, for instance, the mac os x version of LO: unfortunately > it contains tons of accessibility bugs that make impossible to use it > for a blind user [...] > > Just my opinion; maybe I am late, but I decided to share the opinion > from my blind-user waiting for an accessible mac os x version > of lo perspective..." > > So we need to stop this discriminating bug -- finally. Not only does this affect people needing accessibility for, well accessibility, but also people using helper applications like window managers that require access to the accessibility API. Granted that fixing it for the visibility impaired is a much more important cause, but still.
*** Bug 54281 has been marked as a duplicate of this bug. ***
*** Bug 54282 has been marked as a duplicate of this bug. ***
(In reply to comment #31) > Of course, it'd be fantastic to have a stack-trace with full symbols for this > SEGV: > > 0 libsvtlo.dylib 0x00af5de2 > ValueSetAcc::getAccessibleAtPoint(com::sun::star::awt::Point const&) + 146 > 1 libvcllo.dylib 0x01936c31 > hitTestRunner(com::sun::star::awt::Point, The description of bug 54282 has a backtrace containing "hitTestRunner" that looks like arbitrary memory corruption (crashing in pthread_mutex_unlock).
*** Bug 53240 has been marked as a duplicate of this bug. ***
So - this is indeed an horribly high priority bug; but - without more information it seems un-fixable; it is clearly a memory corruption bug: > The description of bug 54282 has a backtrace containing "hitTestRunner" that > looks like arbitrary memory corruption (crashing in pthread_mutex_unlock). so I agree with Stephan. It is also I think clearly related to VCL's -abominable- lack of any hard lifecycle mechanism. As such, there are really only three ways we can find this [ assuming it is reproducible ]: a) binary chop. We need to build around 15 versions of LibreOffice going back in time, to the point that the bug (or it's increase in prevalence) was first introduced - IMHO this is a bug that always existed, so just finding that commit may only bring us a bit nearer to understanding the issue. b) code reading / gdb debugging We need to get good traces with debug symbols - the more precision we have as to which object is bad, the more likely we can find what is going on. This needs a hacker with their own build, -with- debugging symbols, and some clue to delve around / read about. c) valgrind Again, requires a build with debugging symbols to be at all useful; and (if we can reproduce it) will give us an exact pair of line numbers for the problem yielding an ~instant fix. Unfortunately, Norbert couldn't reproduce the problem under valgrind, and/or valgrind on OSX hung LibreOffice (which is a hard nut to crack anyway ;-). My preferred approach is c) it's something that anyone with a build with debugging symbols can work on, and perhaps we'd get some help. We really also need some precise instructions on how to reproduce each of the different symptoms of the underlying issue here that can easily be referred to. Sadly I don't have Mac, so can't help out ...
(In reply to comment #82) > c) valgrind > Again, requires a build with debugging symbols to be at all useful; and > (if we can reproduce it) will give us an exact pair of line numbers for the > problem yielding an ~instant fix. Unfortunately, Norbert couldn't reproduce the > problem under valgrind, and/or valgrind on OSX hung LibreOffice (which is a > hard nut to crack anyway ;-). Yep, I can confirm Norbert's experience of valgrind with my own fruitless attempts about some 6-8 months ago. > > My preferred approach is c) it's something that anyone with a build with > debugging symbols can work on, and perhaps we'd get some help. > LO no longer builds on OSX 10.8 Mountain Lion for me, even with Stephan's script (that appeared to work for him on OSX 10.7), and independently on two different machines, so I currently have no way of building even a normal version of LO on Mac, let alone a debug build, and I'm not a developer by any stretch of the imagination... Alex
For me, LO builds on 10.8.1 with Clang from Xcode 4.4.1 using the following autogen.lastrun: --disable-binfilter --disable-build-mozilla --disable-mozilla --disable-odk --disable-online-update --enable-debug=cppu/ cppuhelper/ sal/ sfx2/ stoc/ sw/ toolkit/ unotest/ unotools/ vcl/ --enable-epm --enable-werror --with-java-target-version=1.5 --with-macosx-version-min-required=10.6 --with-max-jobs=1 --with-num-cpus=1 --without-doxygen --without-help --without-helppack-integration --without-myspell-dicts I am not saying that it has to be *exactly* like that; it's just an example. No 3rd-party software used except autoconf and automake. Whether the crash can be reproduced using a LO built thusly I have no idea; Quickly testing, I couldn't, but then I didn't try very hard. The distributed LO is built using a very different tool-chain anyway. (If I am expected to debug this, I want it clearly said that I can use work time on it.)
(In reply to comment #82) > We really also need some precise instructions on how to reproduce each of the > different symptoms of the underlying issue here that can easily be referred to. If this means that we need a short ‘manual’ listing systematically all known ways to reproduce/trigger this bug, together with step-by-step instructions for each of these ways, and maybe links to the original bug reports, I can take this task ... IMHO a special page in our wiki would be the best solution. Give me some days, and I will create it. (However, if it means something else, please correct me ;-)
(In reply to comment #84) > For me, LO builds on 10.8.1 with Clang from Xcode 4.4.1 using the following > autogen.lastrun: Tor, thanks for the hint. > No 3rd-party software used except autoconf and automake. > Which versions of autoconf and automake do you use ? I see autoconf and automake in /Developer/user/share and /Developer/user/bin, but even when I specifically added those directories to my PATH, I still get an error in autogen.sh about not finding autom4te. On the OSX server machine I have no ports installed, just XCode 4.4.1 Alex
Alex: automake 1.11.3 and autoconf 2.68, built from sources. Do you have a /Developer even if you have Xcode 4.4.1? The latest Xcode installs from the Mac App Store, as a normal self-contained app, as /Applications/Xcode.app, with tverything then under that. At least, that's how it is for me. (Under /Developer I only have some minor leftovers from MonoTouch.) If you have an older version of Xcode, I think automake and autoconf should be present in /usr/bin if you make sure you install the "command-line tools" from inside Xcode. (This no longer happens with the later Xcode versions, for some reason they left out automake and autoconf from the "command-line tools".)
(In reply to comment #87) > Alex: automake 1.11.3 and autoconf 2.68, built from sources. Do you have a > /Developer even if you have Xcode 4.4.1? The latest Xcode installs from the Mac Yes, I was previously building on the same machine under OSX 10.6 with XCode 3.2, then upgraded to 10.8 and XCode 4.4.1, so there appear to be quite a lot of /Developer "leftovers" (in fact what looks like most of the /usr/bin file structure for Unix build tools). > App Store, as a normal self-contained app, as /Applications/Xcode.app, with > tverything then under that. At least, that's how it is for me. (Under > /Developer I only have some minor leftovers from MonoTouch.) If you have an > older version of Xcode, I think automake and autoconf should be present in > /usr/bin if you make sure you install the "command-line tools" from inside > Xcode. (This no longer happens with the later Xcode versions, for some reason > they left out automake and autoconf from the "command-line tools".) Yep, noticed that too, and judging from the comments, made a fair few people unhappy in the process. I definitely don't have those tools in /usr or /usr/bin, so will simply try copying them from /Developer/usr/ over to the corresponding directories, then update automake/autoconf as necessary. Alex
(In reply to comment #87) OK, sussed it, the copy over from /Developer/usr seems to have done the trick. Onto building. Thanks for your help. Alex
Alex: Great you can build! the bt you'll be able to generate with --enable-symbols will be very useful. About LO building process on Mac, I just thought it could be useful to have this kind of info (encountered errors, solution, what to check) there: http://wiki.documentfoundation.org/Development/Install_Mac_OS_10.6.4_Dependencies Obviously, the most important first would be the content not the format. Since you've got a Mac and are interested about building, would you be volunteer for updating wiki? The interesting point is since you're not a developer (as you said! :-)), you may mention explicitely elements that could be implicit for a dev. Of course, nothing mandatory here since you're already doing a great QA job for Base part at least and I know too much that time isn't an expandable resource!:-)
(In reply to comment #90) Hi Julien, > > Since you've got a Mac and are interested about building, would you be > volunteer for updating wiki? > The interesting point is since you're not a developer (as you said! :-)), you > may mention explicitely elements that could be implicit for a dev. I will have a look, but anything I add will be specific to my own particular circumstances I guess. Alex
Can somebody give *exact* reproduction instructions with LibreOffice 3.6.1 on Mac OS X 10.8.1? Preferably using only the OS's own accessibility tools. I have tried with VoiceOver but no crash.
(In reply to comment #92) > Can somebody give *exact* reproduction instructions with LibreOffice 3.6.1 on > Mac OS X 10.8.1? I have only Mac OS X 10.6.8, and can reproduce the crash only with the help of some 3rd party accessibility-related utility (see below), but here are two step-by-step procedures which crash both LibO 3.6.1 and the current master build (I can give more such step-by-step procedures if necessary): I) Adding a cell border in Calc (cf. bug 50467, bug 51791) ---------------------------------------------------------- 0) Rename your LibO user profile folder, to make sure that there is no influence of any special settings on the test (I always do so before such tests). 1) Start LibreOffice; -> the Start Center window appears. 2) In the Start Center window, click "Spreadsheet"; -> a new spreadsheet document is created, cell A1 is already selected. 3) Select "Format > Cells..." from the menu; -> the "Format Cells" dialog window appears. 4) Select the tab "Borders". 5) At top left, under "Line Arrangement" / "Default", select the second item ("Set all four borders"); -> the border preview below changes. 6) Click "OK". -> LibreOffice crashes. II) Selecting a pane in the application Options window (cf. bug 44807, bug 52147, and probably bug 37913) -------------------------------------------------------- 0) Rename your LibO user profile folder, to make sure that there is no influence of any special settings on the test (I always do so before such tests). 1) Start LibreOffice; -> the Start Center window appears. 2) Select "LibreOffice > Preferences..." from the menu; -> the "Options" dialog window appears. 3) In the list at the left side of the window, click on any top-level entry -- I mean, one of the entries "Load/Save", "Language Settings", "LibreOffice Base", "Charts", "Internet", which can be unfolded to show the sub-entries. -> Most times LibreOffice will crash now; if not, click on another top-level entry. It _may_ be necessary that the top-level entry is not unfolded, but closed before you click on it. > Preferably using only the OS's own accessibility tools. Sorry, this is my big problem: I have never managed to reproduce these crashes with the OS's own accessibility tools only; strange (maybe this depends on the Mac OS version? most reports mention Mac OS X 10.7). But I can reproduce the same crashes as reported by the users when I install some window-management utility like Moom, Cinch, RightZoom, ShiftIt, BetterSnapTool ... which all rely on accessibility features. For the tests given above, I have used RightZoom. What I did: 1) Download it, e.g. from http://download.cnet.com/Right-Zoom/3000-18487_4-10909444.html 2) Install it. 3) Start the application "RightZoom". 4) In the 2nd tab "Applications", select "Enable RightZoom in all applications". 5) In the 1st tab, check "Activate RightZoom" and click on "Apply". 6) Quit the RightZoom application. 7) You can now check in the Terminal via "top", if the Daemon (with the same name: RightZoom) is running. z) Later: To remove RightZoom again: start the application; in the 1st tab, check "Activate RightZoom"; click "Apply". >I have tried with VoiceOver but no crash. I would guess that the best candidate is not "VoiceOver", but "Enable access for assistive devices"; this option is the one which is mentioned in most bug reports.
OK, thanks, now I got it to crash, with Right Zoom active. But that was the TDF build of 3.6.1. A self-build of master (built with Clang from Xcode 4.4.1, with debugging information) did not crash, sigh. I will juggle my build tres a bit (I am a bit short on disk space on my Mac) and build a 3.6.1 with the old Xcode 3.2.6 and 10.4 SDK, gcc 4.0, with debugging... that should correspond to the TDF build. (It indeed seems essential to clean out your Library/Application Support/LibreOffice folder between testing different builds of LO for the crash to happen, for some reason.) Anyway, FWIW, for me slot 1 in the backtrace is svx::a11y::AccFrameSelector::LinkStubWindowEventListener(VclSimpleEvent*)+130 (slot 0 is all zeros, as in comment #45).
I built the 3.6 branch with --enable-debug, and reproduced. This indeed is some kind of lifecycle management issue. It seems that svx::a11y::AccFrameSelector::WindowEventListener() in svx/source/accessibility/AccessibleFrameSelector.cxx (defined with the IMPL_LINK macro) gets called after the AccFrameSelector object in question has been destroyed. Some debugging output: AccFrameSelector::AccFrameSelector() this=0xc584b60 AccFrameSelector::AccFrameSelector() this=0xc584de0 <= constructor AccFrameSelector::AccFrameSelector() this=0xc43a0e4 AccFrameSelector::AccFrameSelector() this=0xc43a364 AccFrameSelector::AccFrameSelector() this=0xc43a5e4 AccFrameSelector::AccFrameSelector() this=0xc43a864 AccFrameSelector::AccFrameSelector() this=0xc43aae4 AccFrameSelector::WindowEventListener() this=0xc584b60 AccFrameSelector::WindowEventListener() this=0xc584de0 AccFrameSelector::WindowEventListener() this=0xc43a0e4 AccFrameSelector::WindowEventListener() this=0xc43a364 AccFrameSelector::WindowEventListener() this=0xc43a5e4 AccFrameSelector::WindowEventListener() this=0xc43a864 AccFrameSelector::WindowEventListener() this=0xc43aae4 AccFrameSelector::~AccFrameSelector() this=0xc584de0 <= destructor AccFrameSelector::~AccFrameSelector() this=0xc584de0 returning AccFrameSelector::~AccFrameSelector() this=0xc43a0e4 AccFrameSelector::~AccFrameSelector() this=0xc43a0e4 returning AccFrameSelector::~AccFrameSelector() this=0xc43a364 AccFrameSelector::~AccFrameSelector() this=0xc43a364 returning AccFrameSelector::~AccFrameSelector() this=0xc43a5e4 AccFrameSelector::~AccFrameSelector() this=0xc43a5e4 returning AccFrameSelector::~AccFrameSelector() this=0xc43a864 AccFrameSelector::~AccFrameSelector() this=0xc43a864 returning AccFrameSelector::~AccFrameSelector() this=0xc43aae4 AccFrameSelector::~AccFrameSelector() this=0xc43aae4 returning AccFrameSelector::WindowEventListener() this=0xc584b60 AccFrameSelector::ProcessWindowEvent() this=0xc584b60 AccFrameSelector::WindowEventListener() this=0xc584de0 Program received signal EXC_BAD_ACCESS, Could not access memory. backtrace: #0 0x00000000 in ?? () #1 0x23a3567f in svx::a11y::AccFrameSelector::WindowEventListener (this=0xc584de0, pEvent=0xbfffdccc) at /Users/tml/lo/tdf/svx/source/accessibility/AccessibleFrameSelector.cxx:659 #2 0x23a356a2 in svx::a11y::AccFrameSelector::LinkStubWindowEventListener (pThis=0xc584de0, pCaller=0xbfffdccc) at /Users/tml/lo/tdf/svx/source/accessibility/AccessibleFrameSelector.cxx:648 #3 0x032a2b9b in Link::Call (this=0xbd10fb8, pCaller=0xbfffdccc) at link.hxx:143 #4 0x032c8627 in VclEventListeners::Call (this=0x22736750, pEvent=0xbfffdccc) at /Users/tml/lo/tdf/vcl/source/app/vclevent.cxx:75 #5 0x0364751d in Window::CallEventListeners (this=0x739a6ec, nEvent=1, pData=0x0) at /Users/tml/lo/tdf/vcl/source/window/window.cxx:5184 #6 0x0364761f in Window::ImplCallEventListeners (this=0x739a6ec, nEvent=1, pData=0x0) at /Users/tml/lo/tdf/vcl/source/window/window.cxx:5167 #7 0x03662ba0 in Window::~Window (this=0x739a6ec) at /Users/tml/lo/tdf/vcl/source/window/window.cxx:4210 #8 0x032efda2 in Control::~Control (this=0x739a6ec) at /Users/tml/lo/tdf/vcl/source/control/ctrl.cxx:91 #9 0x23b01d49 in svx::FrameSelector::~FrameSelector (this=0x739a6ec) at /Users/tml/lo/tdf/svx/source/dialog/frmsel.cxx:789 #10 0x25a21dd5 in SvxBorderTabPage::~SvxBorderTabPage (this=0x739a000) at /Users/tml/lo/tdf/cui/source/tabpages/border.cxx:333 #11 0x00ce9d92 in SfxTabDialog::~SfxTabDialog (this=0x6b43e00) at /Users/tml/lo/tdf/sfx2/source/dialog/tabdlg.cxx:495 #12 0x22b69f0a in ScAttrDlg::~ScAttrDlg (this=0x6b43e00) at /Users/tml/lo/tdf/sc/source/ui/attrdlg/attrdlg.cxx:93 #13 0x22b6ea42 in AbstractTabDialog_Impl::~AbstractTabDialog_Impl (this=0x227d5db0) at /Users/tml/lo/tdf/sc/source/ui/attrdlg/scdlgfact.cxx:126 #14 0x2062da22 in ScTabViewShell::ExecuteCellFormatDlg (this=0x6adf800, rReq=@0xbfffecd0, nTabPage=65535) at /Users/tml/lo/tdf/sc/source/ui/view/tabvwsha.cxx:539 #15 0x205486a1 in ScCellShell::Execute (this=0x127e96a0, rReq=@0xbfffecd0) at /Users/tml/lo/tdf/sc/source/ui/view/cellsh3.cxx:357 #16 0x2052fa50 in SfxStubScCellShellExecute (pShell=0x127e96a0, rReq=@0xbfffecd0) at scslots.hxx:6331 #17 0x00c5db70 in SfxShell::CallExec (this=0x127e96a0, pFunc=0x2052fa38 <SfxStubScCellShellExecute(SfxShell*, SfxRequest&)>, rReq=@0xbfffecd0) at shell.hxx:199 #18 0x00c47752 in SfxDispatcher::Call_Impl (this=0x12717a10, rShell=@0x127e96a0, rSlot=@0x20a5c244, rReq=@0xbfffecd0, bRecord=1 '\001') at /Users/tml/lo/tdf/sfx2/source/control/dispatch.cxx:260 #19 0x00c47a8d in SfxDispatcher::_Execute (this=0x12717a10, rShell=@0x127e96a0, rSlot=@0x20a5c244, rReq=@0xbfffecd0, eCallMode=4) at /Users/tml/lo/tdf/sfx2/source/control/dispatch.cxx:943 #20 0x00c3d196 in SfxBindings::Execute_Impl (this=0x1271b5e0, aReq=@0xbfffecd0, pSlot=0x20a5c244, pShell=0x127e96a0) at /Users/tml/lo/tdf/sfx2/source/control/bindings.cxx:1284 #21 0x00c669eb in SfxDispatchController_Impl::dispatch (this=0x226ce850, aURL=@0xbfffee38, aArgs=@0xbfffee7c, rListener=@0xbfffeddc) at /Users/tml/lo/tdf/sfx2/source/control/unoctitm.cxx:748 #22 0x00c67172 in SfxOfficeDispatch::dispatch (this=0xc57ec68, aURL=@0xbfffee38, aArgs=@0xbfffee7c) at /Users/tml/lo/tdf/sfx2/source/control/unoctitm.cxx:377 #23 0x0ca93db2 in framework::MenuBarManager::Select (this=0xc4509d8, pMenu=0xbd045d0) at /Users/tml/lo/tdf/framework/source/uielement/menubarmanager.cxx:1154 #24 0x0ca93e76 in framework::MenuBarManager::LinkStubSelect (pThis=0xc4509d8, pCaller=0xbd045d0) at /Users/tml/lo/tdf/framework/source/uielement/menubarmanager.cxx:1086 #25 0x032a2b9b in Link::Call (this=0xbd04604, pCaller=0xbd045d0) at link.hxx:143 #26 0x035c4bca in Menu::Select (this=0xbd045d0) at /Users/tml/lo/tdf/vcl/source/window/menu.cxx:1135 #27 0x035bf2e8 in Menu::ImplCallSelect (this=0xbd045d0) at /Users/tml/lo/tdf/vcl/source/window/menu.cxx:2978 #28 0x035bf308 in Menu::LinkStubImplCallSelect (pThis=0xbd045d0, pCaller=0x0) at /Users/tml/lo/tdf/vcl/source/window/menu.cxx:2975 #29 0x032a2b9b in Link::Call (this=0x227b6b20, pCaller=0x0) at link.hxx:143 #30 0x0366e816 in ImplHandleUserEvent (pSVEvent=0x227d2f20) at /Users/tml/lo/tdf/vcl/source/window/winproc.cxx:2003 #31 0x036714fb in ImplWindowFrameProc (pWindow=0x6407310, nEvent=22, pEvent=0x227d2f20) at /Users/tml/lo/tdf/vcl/source/window/winproc.cxx:2575 #32 0x036823dd in SalFrame::CallCallback (this=0x64070d0, nEvent=22, pEvent=0x227d2f20) at salframe.hxx:281 #33 0x03681c9f in AquaSalInstance::Yield (this=0x78b2020, bWait=true, bHandleAllCurrentEvents=false) at /Users/tml/lo/tdf/vcl/aqua/source/app/salinst.cxx:735 #34 0x032b3b2b in ImplYield (i_bWait=true, i_bAllEvents=false) at /Users/tml/lo/tdf/vcl/source/app/svapp.cxx:451 #35 0x032b01a8 in Application::Yield (i_bAllEvents=false) at /Users/tml/lo/tdf/vcl/source/app/svapp.cxx:485 #36 0x032b01d0 in Application::Execute () at /Users/tml/lo/tdf/vcl/source/app/svapp.cxx:430 #37 0x000fcd61 in desktop::Desktop::Main (this=0xbffff950) at /Users/tml/lo/tdf/desktop/source/app/app.cxx:1715 #38 0x032bbb6f in ImplSVMain () at /Users/tml/lo/tdf/vcl/source/app/svmain.cxx:183 #39 0x03680ccf in AquaSalInstance::handleAppDefinedEvent (pEvent=0x64b5ec0) at /Users/tml/lo/tdf/vcl/aqua/source/app/salinst.cxx:606 #40 0x036dcdd6 in -[VCL_NSApplication sendEvent:] (self=0x7860d30, _cmd=0x91847963, pEvent=0x64b5ec0) at /Users/tml/lo/tdf/vcl/aqua/source/app/vclnsapp.mm:69 #41 0x90fe373c in -[NSApplication run] () #42 0x90f868e6 in NSApplicationMain () #43 0x0367e8fd in ImplSVMainHook (pnInit=0xbffff90c) at /Users/tml/lo/tdf/vcl/aqua/source/app/salinst.cxx:243 #44 0x032bbc9f in SVMain () at /Users/tml/lo/tdf/vcl/source/app/svmain.cxx:217 #45 0x0012c855 in soffice_main () at /Users/tml/lo/tdf/desktop/source/app/sofficemain.cxx:85 #46 0x00001f26 in sal_main () at /Users/tml/lo/tdf/desktop/source/app/main.c:34 #47 0x00001f0e in main (argc=1, argv=0xbffffa3c) at /Users/tml/lo/tdf/desktop/source/app/main.c:33 I am a bit clueless about how this LINK stuff works, but will try to see what I can figure out... (It's fun that googling for related stuff, I found some OOo experts calling the LINK mechanism obsolete or old already in 2003...)
The problem turned out to be pretty trivial and localized after all. (I am not sure if using valgrind would have helped much, but anyway, valgrind does not work on OS X 10.8, not even a bleeding edge svn version.) The problem is that in the AccFrameSelector destructor RemoveEventListener is called, but only if the mpFrameSel member is non-null. Unfortunately, in the Invalidate() method mpFrameSel is set to zero but the event listener is not removed. So when the object is destructed, as mpFrameSel is null, the event listener does not get removed, but stays active, even if associated with a dead object. The solution is to remove the event listener also in Invalidate(). I added a new tiny function for that.
Created attachment 66880 [details] Suggested patch Pushed to master, verifying and cherry-picking appreciated.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9b9d45e35103e6884e0a87c35c07c74899f40614 fdo#47368: Remove event listener also in Invalidate() 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.
The above patch fixes only the I) case in comment 93.
For case II, there is an *awful* lot of recursion going on in hitTestRunner(). By an odd coincidence (?), the recursion ends before the thread runs out of stack space though. But then some thirty call stack slots deeper it does, anyway: #0 0x91aa5ef1 in pthread_mutex_lock () #1 0x000068f9 in osl_acquireMutex (Mutex=0x787e6e0) at /Users/tml/lo/tdf/sal/osl/unx/mutex.c:123 #2 0x00821801 in osl::Mutex::acquire (this=0x787e6d0) at mutex.hxx:67 #3 0x0082e4f7 in osl::Guard<osl::Mutex>::Guard (this=0xbf80011c, t=@0x787e6d0) at mutex.hxx:153 #4 0x008c3940 in com::sun::star::uno::WeakReferenceHelper::get (this=0x257dd3f4) at /Users/tml/lo/tdf/cppuhelper/source/weak.cxx:521 #5 0x0083d00d in com::sun::star::uno::WeakReferenceHelper::operator com::sun::star::uno::Reference<com::sun::star::uno::XInterface> (this=0x257dd3f4) at weakref.hxx:108 #6 0x008c3c23 in cppu::OWeakAggObject::acquire (this=0x257dd3e0) at /Users/tml/lo/tdf/cppuhelper/source/weak.cxx:269 #7 0x00879bbb in cppu::WeakAggComponentImplHelperBase::acquire (this=0x257dd3e0) at /Users/tml/lo/tdf/cppuhelper/source/implbase.cxx:367 #8 0x235e48d3 in cppu::WeakAggComponentImplHelper8<com::sun::star::accessibility::XAccessible, com::sun::star::accessibility::XAccessibleContext, com::sun::star::accessibility::XAccessibleComponent, com::sun::star::accessibility::XAccessibleEventBroadcaster, com::sun::star::accessibility::XAccessibleAction, com::sun::star::accessibility::XAccessibleSelection, com::sun::star::accessibility::XAccessibleText, com::sun::star::lang::XServiceInfo>::acquire (this=0x257dd3e0) at compbase8.hxx:158 #9 0x0082189a in com::sun::star::uno::cpp_acquire (pCppI=0x257dd3e0) at genfunc.hxx:48 #10 0x0071f77d in cppu::_acquire (p=0x257dd3e0, acquire=0x821882 <com::sun::star::uno::cpp_acquire(void*)>) at prim.hxx:88 #11 0x0073dae2 in cppu::_copyConstructAnyFromData (pDestAny=0xbf8004d0, pSource=0xbf800370, pType=0x787fb50, pTypeDescr=0x0, acquire=0x821882 <com::sun::star::uno::cpp_acquire(void*)>, mapping=0x0) at copy.hxx:329 #12 0x0071d015 in cppu::_copyConstructAny (pDestAny=0xbf8004d0, pSource=0xbf800370, pType=0x787fb50, pTypeDescr=0x0, acquire=0x821882 <com::sun::star::uno::cpp_acquire(void*)>, mapping=0x0) at copy.hxx:371 #13 0x0071c888 in uno_type_any_construct (pDest=0xbf8004d0, pSource=0xbf800370, pType=0x787fb50, acquire=0x821882 <com::sun::star::uno::cpp_acquire(void*)>) at /Users/tml/lo/tdf/cppu/source/uno/any.cxx:81 #14 0x0082d253 in com::sun::star::uno::Any::Any (this=0xbf8004d0, pData_=0xbf800370, rType=@0x63ba148) at Any.hxx:81 #15 0x008c5d34 in cppu::queryInterface<com::sun::star::uno::XInterface, com::sun::star::uno::XAggregation, com::sun::star::uno::XWeak> (rType=@0x63ba148, p1=0x257dd3e0, p2=0x257dd3f0, p3=0x257dd3e0) at queryinterface.hxx:102 #16 0x008c49e8 in cppu::OWeakAggObject::queryAggregation (this=0x257dd3e0, rType=@0x63ba148) at /Users/tml/lo/tdf/cppuhelper/source/weak.cxx:300 #17 0x0087aa83 in cppu::WeakAggComponentImplHelperBase::queryAggregation (this=0x257dd3e0, rType=@0x63ba148) at /Users/tml/lo/tdf/cppuhelper/source/implbase.cxx:361 #18 0x0087c63c in cppu::WeakAggComponentImplHelper_queryAgg (rType=@0x63ba148, cd=0x236ae180, that=0x257dd3e0, pBase=0x257dd3e0) at /Users/tml/lo/tdf/cppuhelper/source/implbase_ex.cxx:451 #19 0x235e4aad in cppu::WeakAggComponentImplHelper8<com::sun::star::accessibility::XAccessible, com::sun::star::accessibility::XAccessibleContext, com::sun::star::accessibility::XAccessibleComponent, com::sun::star::accessibility::XAccessibleEventBroadcaster, com::sun::star::accessibility::XAccessibleAction, com::sun::star::accessibility::XAccessibleSelection, com::sun::star::accessibility::XAccessibleText, com::sun::star::lang::XServiceInfo>::queryAggregation (this=0x257dd3e0, rType=@0x63ba148) at compbase8.hxx:156 #20 0x008c3b69 in cppu::OWeakAggObject::queryInterface (this=0x257dd3e0, rType=@0x63ba148) at /Users/tml/lo/tdf/cppuhelper/source/weak.cxx:290 #21 0x00879b9e in cppu::WeakAggComponentImplHelperBase::queryInterface (this=0x257dd3e0, rType=@0x63ba148) at /Users/tml/lo/tdf/cppuhelper/source/implbase.cxx:350 #22 0x235e4848 in cppu::WeakAggComponentImplHelper8<com::sun::star::accessibility::XAccessible, com::sun::star::accessibility::XAccessibleContext, com::sun::star::accessibility::XAccessibleComponent, com::sun::star::accessibility::XAccessibleEventBroadcaster, com::sun::star::accessibility::XAccessibleAction, com::sun::star::accessibility::XAccessibleSelection, com::sun::star::accessibility::XAccessibleText, com::sun::star::lang::XServiceInfo>::queryInterface (this=0x257dd3e0, rType=@0x63ba148) at compbase8.hxx:154 #23 0x0082644d in com::sun::star::uno::BaseReference::iquery (pInterface=0x257dd410, rType=@0x63ba148) at Reference.hxx:52 #24 0x008c5b31 in com::sun::star::uno::Reference<com::sun::star::uno::XWeak>::iquery (pInterface=0x257dd410) at Reference.hxx:67 #25 0x008c5da4 in com::sun::star::uno::Reference<com::sun::star::uno::XWeak>::query (rRef=@0xbf80067c) at Reference.hxx:351 #26 0x008c4a48 in com::sun::star::uno::OWeakRefListener::OWeakRefListener (this=0x26861270, xInt=@0xbf80067c) at /Users/tml/lo/tdf/cppuhelper/source/weak.cxx:374 #27 0x008c5067 in com::sun::star::uno::WeakReferenceHelper::WeakReferenceHelper (this=0x257dd538, xInt=@0xbf80067c) at /Users/tml/lo/tdf/cppuhelper/source/weak.cxx:448 #28 0x235e31f6 in com::sun::star::uno::WeakReference<com::sun::star::accessibility::XAccessible>::WeakReference (this=0x257dd538, rRef=@0xbf80067c) at weakref.hxx:142 #29 0x235e162c in accessibility::AccessibleListBoxEntry::AccessibleListBoxEntry (this=0x257dd4a0, _rListBox=@0x687832c, _pEntry=0x1f0625c0, _xParent=@0xbf80067c) at /Users/tml/lo/tdf/accessibility/source/extended/accessiblelistboxentry.cxx:86 #30 0x235e1b43 in accessibility::AccessibleListBoxEntry::getAccessibleAtPoint (this=0x257dd3e0, _aPoint=@0xbf800704) at /Users/tml/lo/tdf/accessibility/source/extended/accessiblelistboxentry.cxx:483 #31 0x036d76f6 in hitTestRunner (point={X = 299, Y = 417}, rxAccessibleContext=@0xbf8007e4) at /Users/tml/lo/tdf/vcl/aqua/source/a11y/aqua11ywrapper.mm:981 #32 0x036d78cd in hitTestRunner (point={X = 299, Y = 417}, rxAccessibleContext=@0xbf800894) at /Users/tml/lo/tdf/vcl/aqua/source/a11y/aqua11ywrapper.mm:984 #33 0x036d78cd in hitTestRunner (point={X = 299, Y = 417}, rxAccessibleContext=@0xbf800944) at /Users/tml/lo/tdf/vcl/aqua/source/a11y/aqua11ywrapper.mm:984 #34 0x036d78cd in hitTestRunner (point={X = 299, Y = 417}, rxAccessibleContext=@0xbf8009f4) at /Users/tml/lo/tdf/vcl/aqua/source/a11y/aqua11ywrapper.mm:984 #35 0x036d78cd in hitTestRunner (point={X = 299, Y = 417}, rxAccessibleContext=@0xbf800aa4) at /Users/tml/lo/tdf/vcl/aqua/source/a11y/aqua11ywrapper.mm:984 #36 0x036d78cd in hitTestRunner (point={X = 299, Y = 417}, rxAccessibleContext=@0xbf800b54) at /Users/tml/lo/tdf/vcl/aqua/source/a11y/aqua11ywrapper.mm:984 #37 0x036d78cd in hitTestRunner (point={X = 299, Y = 417}, rxAccessibleContext=@0xbf800c04) at /Users/tml/lo/tdf/vcl/aqua/source/a11y/aqua11ywrapper.mm:984 #38 0x036d78cd in hitTestRunner (point={X = 299, Y = 417}, rxAccessibleContext=@0xbf800cb4) at /Users/tml/lo/tdf/vcl/aqua/source/a11y/aqua11ywrapper.mm:984 #39 0x036d78cd in hitTestRunner (point={X = 299, Y = 417}, rxAccessibleContext=@0xbf800d64) at /Users/tml/lo/tdf/vcl/aqua/source/a11y/aqua11ywrapper.mm:984 (*thousands* of hitTestRunner slots below that, gdb just prints and prints line after line, I didn't have the patience to wait if it ever stops... Or maybe gdb gets totally confused by something.) Anyway, (gdb) p $esp $7 = (void *) 0xbf7ffff0 and the stack bottom is at 0xbf800000: Stack bf800000-bf96d000 [ 1460K] rw-/rwx SM=COW thread 0
Running gdb on the TDF build of 3.6.1, getting a backtrace through all the levels of hitTestRunner recursion is a lot faster (as there is no debugging info, it doesn't have any parameter values or source file locations to print out). It took only some tens of seconds, and around 58000 stack levels up it is out of the recursion;) So gdb does not seem to be confused, there really *is* an unbelievable amount of recursion going on here... Well, even if gdb is not confused, *I* certainly am.
Ah, sorry, I am an idiot, of course there is no odd coincidence going on, the recursion has not ended, it just happens to be relatively deep in a call from hitTestRunner() when it runs out of stack. So the real problem is indeed to figure out why the recursion is infinite.
(In reply to comment #102) > Ah, sorry, I am an idiot, of course there is no odd coincidence going on, the > recursion has not ended, it just happens to be relatively deep in a call from > hitTestRunner() when it runs out of stack. So the real problem is indeed to > figure out why the recursion is infinite. could http://cgit.freedesktop.org/libreoffice/core/commit/?id=27e3ac22295 be related ?
Perhaps, but by itself that change does not help. I tried various ways in hitTestRunner() to figure out if the recursion is going to be infinite, but without success. Of course, I have no clue what this code actually is doing... but clearly in some way it thinks that it is recursing down into children but in fact it isn't, it's all the time staying at the same "level". Or something. Sigh.
Actually it is not a good thing at all that we have this one bug report for several unrelated crashes (with the only relation being that they happen only if some accessibility tool is turned on). After all, we don't bundle all other crashes into one bug report "crashes when accessibility tools are not enabled" either, do we? The bug described by case I) in comment #93 is now fixed (in master), to tbe best of my understanding. But case II) is not. No idea about all the other unrelated crashes that this bug might be about.
Yes, something seems to be going wrong here, that can't be handled that way as Tor explained, currently it's very difficult to keep overview what problems already have been fixed for what versions and what other ones still are waiting for a fix. IMHO we should - Make this one (or a different one) a Task bug for tracking these problems - Leave those DUPs what have only a very general description "crashes when accessibility enabled " as DUPS of the task bug - Change many oft the other DUPs what have a detailed description concerning the roots of the crashes from "DUP of" to "Blocks Task Bug", so that we have a separate Bug report for each bug causing such a crash. I have too few knowledge concerning details so that I can't do the job.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=06c1c15b706870c2a134bc14845e25a8b30cdac1&g=libreoffice-3-6 fdo#47368: Remove event listener also in Invalidate() It will be available in LibreOffice 3.6.2. 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.
nice work Tor - sorry for the confused bug; we had a lot of a11y related issues stacked on top of each other here I guess. I pushed the patch to -3-6; I wonder if fixing case II nails the rest of these ;-) I suspect this may be the bug that never dies. Nevertheless if we can fix case II, then I guess we can keep this closed and re-assess duplicates as/when they get re-opened vs. more recent versions.
Created attachment 66904 [details] potential infinite recursion fix (?) I couldn't correlate your line-numbers with mine; but if the recursion happens in the first hitTest - then it's possible that if the getAccessibleAtPoint returns the same AccessibleContext as the one we're passed we'll hit an infinite loop. Any chance of testing the attached ? :-)
Created attachment 66907 [details] a new patch
First of all: *** Many many thanks to Tor *** *** for his great debugging work! *** ******************************* (In reply to comment #105) > Actually it is not a good thing at all that we have this one bug report for > several unrelated crashes (with the only relation being that they happen only > if some accessibility tool is turned on). You are completey right. This problem (the confused bug report) has historical reasons: at the beginning, simple-minded QA volunteers like me thought that we really had only one bug with some duplicates; as time went by, we realized that more than one bug was involved, maybe a complete rat nest of bugs, but it was already so common to mark all Mac accesibility related issues as duplicates of this bug that no one wanted to change this procedure ... > The bug described by case I) in comment #93 is now fixed (in master), to tbe > best of my understanding. But case II) is not. No idea about all the other > unrelated crashes that this bug might be about. IIRC many of the Mac accesibility bug reports show similar stack traces, therefore I still hope that we don’t have 30 or more different Mac accesibility related bugs, but a small number of bugs, each of them with many duplicates. But to find out about this, and to make it easier to fix the remaining issues, it seems necessary that we QA folks follow Rainer’s suggestion: (In reply to comment #106) > IMHO we should > - Make this one (or a different one) a Task bug for tracking these problems > - Leave those DUPs what have only a very general description > "crashes when accessibility enabled " as DUPS of the task bug > - Change many oft the other DUPs what have a detailed description concerning > the roots of the crashes from "DUP of" to "Blocks Task Bug", so that we > have a separate Bug report for each bug causing such a crash. Having already spent much time with all these different Mac accesibility related issues, and therefore knowing most of them, I can take this job, if a) I get some approval to do so (we should not have two people do the same job at the same time ;-), and b) we are willing to wait some days -- browsing all the related bug reports and sorting them will take quite some time ... Should I begin?
Michael Meeks committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3234b715b5a6d13ee673b41066eb565706be5ec9 fdo#47368: Fix for infinite recursion 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=7494e0a8d15386f4b962649e4286ddb05732355f&g=libreoffice-3-6 fdo#47368: Fix for infinite recursion It will be available in LibreOffice 3.6.2. 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.
Roman: Your offer sounds lovely, thanks! Do we have daily builds of the 3.6 branch for the Mac? If not, I could also send you the new versions of the two .dylib files in question that you could replace the ones inside the TDF 3.6.1 .app with to test... (Assuming that works.)
Agreed - many thanks to Tor ! :-) The fixes should be in 3.6.2rc1 which is just coming up for freeze, and then (IIRC) we should have 2x weeks to nail down exactly which of these we did in fact fix - and split the rest out of this bug. I'd rather like to mark it fixed however at this point :-)
(In reply to comment #114) > Roman: Your offer sounds lovely, thanks! Thank you for the answer! OK, I will take it ... > Do we have daily builds of the 3.6 branch for the Mac? If not, I could also > send you the new versions of the two .dylib files in question that you could > replace the ones inside the TDF 3.6.1 .app with to test... (Assuming that > works.) Thank you for your offer! But luckily, we have Mac daily builds of the 3.6 branch at http://dev-builds.libreoffice.org/daily/MacOSX-Intel@3-OSX_10.6.0-gcc_4.0.1/libreoffice-3-6/ -- so no library replacement is necessary.
I want to share some GOOD NEWS with you: Testing our LibreOffice 3.6 daily builds, I can still reproduce both issues, I and II (see comment 93), with LibreOffice 3.6.2.0+ (Build ID: cfbfa26) Pull time: 2012-09-07 10:35:10 But I can NOT reproduce them anymore, at least not by the easy steps listed in comment 93, with LibreOffice 3.6.2.0+ (Build ID: c303961) Pull time: 2012-09-11 08:49:57 This is the first daily build which includes Tor's and Michael's fixes (see comment 107 and comment 113). This means very probably that the roots of both crashes I and II have been really fixed, once and forever. So: thank you very much again, Tor and Michael! More good news: While I am still sorting all the possibly related issues (cf. comment 111, comment 115; please be patient, I will upcome with a comprehensive and well-sorted list soon!), I can already say that many of these issues are so similar to our test cases I and II, that there are good chances that many of them have been fixed, too, by these two patches.
Roman - that -is- great news :-) I'm going to close this FIXED then until further notice; any new a11y bugs we should split out into their own new trackers :-) Many thanks for testing & for all who reported bugs, and helped to find a solution - much appreciated !
A little update: I have to ask you all for some patience. Since 3 days, I am sorting and testing all known bugs which are (or could be) related to Mac OS accessibility features. It will take me some more days to complete this survey, because I need to test every bug with at least 4 different LibO builds, and often the steps to reproduce a bug are not very easy to understand. I am leaving a detailed comment about my results in every bug report, so you can see which bugs have already been revisited. My plan is (simplified!): * Every bug which was reproducible with LibO 3.6.1 and LOdev master BEFORE Tor’s and Michael’s two patches (which fixed the two issues listed here in comment 93), but is NOT reproducible anymore AFTER these patches have been applied, should stay marked as a duplicate of the present bug; because if it was fixed by the same patches, it had the same roots. * Every bug which is still reproducible AFTER these two patches have been applied will be reopened. If some of them are related to each other, I will to try to group them by marking them as duplicates of each other, etc. * Other bugs (which I can’t reproduce or are very unclear) will be reopened or set to NEEDINFO, depending on the specific bug situation. * After completing my survey, I will create a new task bug -- this time a real straightforward task bug, similar to our MAB bugs --, to which I will add as “Depends on” all remaining issues, so that we can easily track them down. (I will NOT use the present bug report as task bug, because it is already far too long and confused.) The idea is to find out which bugs are related and which are not, so that at the end we will NOT have yet another confused task bug with 30 or so singular bugs in the "Depends on field", but a simple and clean task bug which only lists (hopefully) 5 or 6 remaining issues, all well-sorted and well-documented. If you want to discuss about this, please write to me directly at bugs@eikota.de, or discuss this on the QA mailing list. The present bug report, already far too long, is IMHO not a good place to do so ;-) So, again: please be patient.
Created attachment 67635 [details] HTML document: “Results of a survey of all LibreOffice bug reports related to Mac OS X accessibility features” Results of a survey of all known LibreOffice bug reports related to Mac OS X accessibility features -------------------------------------------------------- Attached to this comment you will find a detailed summary of my test results (document in HTML format). Here are the most important points: * According to my test results, Tor’s and Michael’s patches have truly fixed “[m]any crashes when accessibility enabled on Mac OS X” ;–): bug 33359, bug 44807, bug 46981, bug 47015, bug 49623, bug 49942, bug 50467, bug 50710, bug 51712, bug 51791, bug 52147, bug 53221, bug 53240, bug 54281, bug 54282, and maybe some more. So all these bug reports are duplicates of the present one. * The following bugs are no longer reproducible with LibreOffice 3.6.1: bug 42014, bug 42866, bug 44471, bug 44807, bug 47569, bug 50147, bug 50769, bug 51686, bug 52014. * Bugs set to NEEDINFO status: bug 31919, bug 37913, bug 39701, bug 40301, bug 47250. * Bugs still reproducible (status NEW or REOPENED): bug 47275 (duplicate: bug 52342), bug 55156 (with some unclear duplicates). These results are very encouraging; they mean that Tor’s and Michael’s patches have improved the situation strongly. So thanks again to Tor and Michael! * These results also confirm that the present bug is (and should stay) RESOLVED FIXED. So please do NOT open the present bug report again! If you can reproduce any bug related to Mac OS X accessibility features with LibreOffice >= 3.6.2, please check first if it is the same issue as any of the bugs listed above as NEW/REOPENED (bug 47275, bug 55156) or as NEEDINFO (bug 31919, bug 37913, bug 39701, bug 40301, bug 47250). -- If yes, please add an additional comment to the particular bug report, if you can contribute some useful information about the issue. -- If no, please file a new bug report for the issue. Thank you!
A last update: In comment #120, I announced to create “a new task bug -- this time a real straightforward task bug, similar to our MAB bugs --, to which I will add as ‘Depends on’ all remaining issues, so that we can easily track them down.” This tracking bug has now been created; it is bug 55571, to which all new important bugs related to the Mac accessibility API should be added. At the moment, there is only one NEW issue listed there; all other known issues are either fixed or no longer reproducible or in NEEDINFO status. To make it easier to see even for newbies, that the present bug should not be opened again, I set its status to CLOSED/FIXED. Thank you all, and see you (if necessary) on bug 55571! ;-)