Bug 47368 - Many crashes when accessibility enabled on MacOS X
Summary: Many crashes when accessibility enabled on MacOS X
Status: CLOSED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.5.1 release
Hardware: Other macOS (All)
: highest critical
Assignee: Not Assigned
URL:
Whiteboard: target:3.7.0 target:3.6.2
Keywords:
: 44807 47015 50467 51712 52147 53221 53240 54281 54282 (view as bug list)
Depends on:
Blocks: a11y-macOS mab3.5
  Show dependency treegraph
 
Reported: 2012-03-15 08:52 UTC by Toni Lähdekorpi
Modified: 2012-10-03 11:32 UTC (History)
28 users (show)

See Also:
Crash report or crash signature:


Attachments
EXC_BAD_ACCESS (43.52 KB, text/plain)
2012-03-16 00:43 UTC, Toni Lähdekorpi
Details
prototype patch for testing ... (784 bytes, patch)
2012-07-23 13:11 UTC, Michael Meeks
Details
Crash log - LOdev 2012-07-24 - Writer, add bkg color to paragraph (61.21 KB, text/plain)
2012-07-24 16:27 UTC, Roman Eisele
Details
Suggested patch (1.90 KB, patch)
2012-09-09 11:59 UTC, Don't use this account, use tml@iki.fi
Details
potential infinite recursion fix (?) (1.18 KB, patch)
2012-09-10 08:20 UTC, Michael Meeks
Details
a new patch (1.63 KB, patch)
2012-09-10 09:19 UTC, Michael Meeks
Details
HTML document: “Results of a survey of all LibreOffice bug reports related to Mac OS X accessibility features” (20.67 KB, text/html)
2012-09-24 16:00 UTC, Roman Eisele
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Toni Lähdekorpi 2012-03-15 08:52:35 UTC
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.
Comment 1 Toni Lähdekorpi 2012-03-15 09:00:33 UTC
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
Comment 2 Julien Nabet 2012-03-15 15:20:47 UTC
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.
Comment 3 Toni Lähdekorpi 2012-03-16 00:43:26 UTC
Created attachment 58540 [details]
EXC_BAD_ACCESS
Comment 4 Toni Lähdekorpi 2012-03-16 00:49:42 UTC
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.
Comment 5 Toni Lähdekorpi 2012-03-16 00:52:26 UTC
Hmm, I just tested disabling accessibility and so far no crashes.
Comment 6 Petr Mladek 2012-03-20 08:37:54 UTC
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.
Comment 7 Alex Thurgood 2012-03-21 01:01:40 UTC
(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
Comment 8 Toni Lähdekorpi 2012-03-21 02:50:37 UTC
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.
Comment 9 Julien Nabet 2012-03-21 03:44:46 UTC
(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
Comment 10 Alex Thurgood 2012-03-23 10:21:21 UTC
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
Comment 11 Alex Thurgood 2012-03-23 10:38:02 UTC
(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
Comment 12 Alex Thurgood 2012-03-23 10:43:25 UTC
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
Comment 13 Toni Lähdekorpi 2012-03-23 10:51:47 UTC
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...
Comment 14 Toni Lähdekorpi 2012-03-23 10:54:31 UTC
Spoke too soon... "Segmentation fault: 11" when changing border width.
Comment 15 Julien Nabet 2012-03-23 16:21:41 UTC
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.
Comment 16 Julien Nabet 2012-03-29 12:09:42 UTC
*** Bug 47015 has been marked as a duplicate of this bug. ***
Comment 17 Julien Nabet 2012-03-29 12:14:25 UTC
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.
Comment 18 Alex Thurgood 2012-03-31 03:57:02 UTC
*** Bug 47569 has been marked as a duplicate of this bug. ***
Comment 19 Alex Thurgood 2012-03-31 04:19:30 UTC
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
Comment 20 mete.gokhan 2012-03-31 15:34:10 UTC
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.
Comment 21 Alex Thurgood 2012-04-02 00:21:51 UTC
(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
Comment 22 mete.gokhan 2012-04-02 02:01:25 UTC
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
Comment 23 Julien Nabet 2012-04-09 12:04:43 UTC
*** Bug 37913 has been marked as a duplicate of this bug. ***
Comment 24 Michael Stahl (allotropia) 2012-05-21 14:10:44 UTC
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...
Comment 25 Roman Eisele 2012-05-24 00:19:29 UTC
*** Bug 50147 has been marked as a duplicate of this bug. ***
Comment 26 Roman Eisele 2012-06-28 08:38:27 UTC
*** Bug 50769 has been marked as a duplicate of this bug. ***
Comment 27 Julien Nabet 2012-07-04 12:20:11 UTC
*** Bug 51712 has been marked as a duplicate of this bug. ***
Comment 28 Roman Eisele 2012-07-11 09:12:19 UTC
*** Bug 44807 has been marked as a duplicate of this bug. ***
Comment 29 Roman Eisele 2012-07-11 14:05:23 UTC
I have nominated this as a "LibreOffice 3.5 most annoying bug" -- see my explanation in bug 37361.
Comment 30 Roman Eisele 2012-07-11 19:14:20 UTC
*** Bug 51791 has been marked as a duplicate of this bug. ***
Comment 31 Michael Meeks 2012-07-12 09:21:29 UTC
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.
Comment 32 Michael Meeks 2012-07-12 10:59:43 UTC
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.
Comment 33 Michael Meeks 2012-07-12 11:06:32 UTC
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.
Comment 34 Roman Eisele 2012-07-15 17:34:39 UTC
*** Bug 44471 has been marked as a duplicate of this bug. ***
Comment 35 Norbert Thiebaud 2012-07-15 21:56:41 UTC
(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...
Comment 36 Roman Eisele 2012-07-16 07:08:35 UTC
*** Bug 51686 has been marked as a duplicate of this bug. ***
Comment 37 Michael Meeks 2012-07-16 10:44:03 UTC
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).
Comment 38 Roman Eisele 2012-07-17 06:24:31 UTC
*** Bug 52147 has been marked as a duplicate of this bug. ***
Comment 39 Stephan Bergmann 2012-07-17 09:49:37 UTC
(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.
Comment 40 Michael Meeks 2012-07-20 15:18:37 UTC
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.
Comment 41 Norbert Thiebaud 2012-07-21 18:20:59 UTC
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....
Comment 42 Roman Eisele 2012-07-21 19:15:46 UTC
(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!
Comment 43 Roman Eisele 2012-07-22 08:51:21 UTC
(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).
Comment 44 Roman Eisele 2012-07-22 09:20:05 UTC
(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.
Comment 45 Norbert Thiebaud 2012-07-22 11:59:30 UTC
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
Comment 46 Roman Eisele 2012-07-22 13:30:29 UTC
(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.)
Comment 47 Norbert Thiebaud 2012-07-22 14:07:50 UTC
(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
Comment 48 Roman Eisele 2012-07-22 14:15:50 UTC
*** Bug 47275 has been marked as a duplicate of this bug. ***
Comment 49 Rainer Bielefeld Retired 2012-07-22 20:34:31 UTC
Due to the DUPs "Bug 52342 - AutoFilter CRASH", "Bug 47275 - Autofilter CRASH" it's now more or less "All LibO apps."
Comment 50 Michael Meeks 2012-07-23 13:11:09 UTC
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.
Comment 51 Not Assigned 2012-07-23 13:57:45 UTC
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
Comment 52 Not Assigned 2012-07-23 15:16:02 UTC
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.
Comment 53 Roman Eisele 2012-07-23 15:40:58 UTC
(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 ...
Comment 54 Norbert Thiebaud 2012-07-23 15:46:35 UTC
(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 :-(
Comment 55 Roman Eisele 2012-07-23 16:04:07 UTC
(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 ... ;-)
Comment 56 Not Assigned 2012-07-24 08:21:10 UTC
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.
Comment 57 Roman Eisele 2012-07-24 10:02:48 UTC
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 ...
Comment 58 Roman Eisele 2012-07-24 10:11:19 UTC
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.
Comment 59 Michael Meeks 2012-07-24 13:18:46 UTC
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 :-)
Comment 60 Roman Eisele 2012-07-24 14:21:28 UTC
(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.
Comment 61 Roman Eisele 2012-07-24 16:27:01 UTC
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 ;-)
Comment 62 Michael Meeks 2012-07-24 18:54:12 UTC
> I fear "we need to think again"

Ok - then we badly need that valgrind trace - Norbert ? :-) ...
Comment 63 Roman Eisele 2012-07-25 09:16:27 UTC
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?)
Comment 64 Thorsten Behrens (allotropia) 2012-07-25 10:07:17 UTC
(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. ;)
Comment 65 Michael Meeks 2012-07-25 11:16:16 UTC
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 ...
Comment 66 Roman Eisele 2012-07-25 12:36:22 UTC
(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).
Comment 67 Not Assigned 2012-07-25 17:53:48 UTC
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.
Comment 68 Roman Eisele 2012-08-04 10:51:43 UTC
(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.
Comment 69 Julien Nabet 2012-08-09 07:24:42 UTC
*** Bug 53221 has been marked as a duplicate of this bug. ***
Comment 70 Roman Eisele 2012-08-16 10:07:36 UTC
*** Bug 50710 has been marked as a duplicate of this bug. ***
Comment 71 Roman Eisele 2012-08-22 08:30:16 UTC
*** Bug 50467 has been marked as a duplicate of this bug. ***
Comment 72 Roman Eisele 2012-08-24 15:30:04 UTC
*** Bug 42866 has been marked as a duplicate of this bug. ***
Comment 73 Roman Eisele 2012-08-25 09:46:39 UTC
No "See also" for bug 44807 necessary, if bug 44807 is already marked as a duplicate of the present bug.
Comment 74 Roman Eisele 2012-08-25 09:48:11 UTC
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?
Comment 75 Roman Eisele 2012-08-25 09:52:32 UTC
*** Bug 33359 has been marked as a duplicate of this bug. ***
Comment 76 Roman Eisele 2012-08-30 10:13:50 UTC
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.)
Comment 77 Toni Lähdekorpi 2012-08-30 14:15:25 UTC
(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.
Comment 78 Roman Eisele 2012-08-31 11:41:15 UTC
*** Bug 54281 has been marked as a duplicate of this bug. ***
Comment 79 Stephan Bergmann 2012-08-31 16:06:26 UTC
*** Bug 54282 has been marked as a duplicate of this bug. ***
Comment 80 Stephan Bergmann 2012-08-31 16:09:58 UTC
(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).
Comment 81 Roman Eisele 2012-09-01 11:47:32 UTC
*** Bug 53240 has been marked as a duplicate of this bug. ***
Comment 82 Michael Meeks 2012-09-04 11:02:07 UTC
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 ...
Comment 83 Alex Thurgood 2012-09-05 08:23:40 UTC
(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
Comment 84 Don't use this account, use tml@iki.fi 2012-09-05 08:46:52 UTC
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.)
Comment 85 Roman Eisele 2012-09-05 09:39:39 UTC
(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 ;-)
Comment 86 Alex Thurgood 2012-09-05 11:17:17 UTC
(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
Comment 87 Don't use this account, use tml@iki.fi 2012-09-05 11:30:02 UTC
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".)
Comment 88 Alex Thurgood 2012-09-05 11:45:24 UTC
(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
Comment 89 Alex Thurgood 2012-09-05 11:49:32 UTC
(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
Comment 90 Julien Nabet 2012-09-05 12:15:50 UTC
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!:-)
Comment 91 Alex Thurgood 2012-09-05 12:28:40 UTC
(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
Comment 92 Don't use this account, use tml@iki.fi 2012-09-06 18:20:55 UTC
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.
Comment 93 Roman Eisele 2012-09-07 09:43:25 UTC
(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.
Comment 94 Don't use this account, use tml@iki.fi 2012-09-07 11:27:35 UTC
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).
Comment 95 Don't use this account, use tml@iki.fi 2012-09-09 11:09:45 UTC
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...)
Comment 96 Don't use this account, use tml@iki.fi 2012-09-09 11:57:02 UTC
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.
Comment 97 Don't use this account, use tml@iki.fi 2012-09-09 11:59:30 UTC
Created attachment 66880 [details]
Suggested patch

Pushed to master, verifying and cherry-picking appreciated.
Comment 98 Not Assigned 2012-09-09 12:02:58 UTC
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.
Comment 99 Don't use this account, use tml@iki.fi 2012-09-09 12:05:35 UTC
The above patch fixes only the I) case in comment 93.
Comment 100 Don't use this account, use tml@iki.fi 2012-09-09 13:21:24 UTC
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
Comment 101 Don't use this account, use tml@iki.fi 2012-09-09 14:07:31 UTC
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.
Comment 102 Don't use this account, use tml@iki.fi 2012-09-09 15:35:46 UTC
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.
Comment 103 Norbert Thiebaud 2012-09-09 16:18:45 UTC
(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 ?
Comment 104 Don't use this account, use tml@iki.fi 2012-09-09 17:45:21 UTC
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.
Comment 105 Don't use this account, use tml@iki.fi 2012-09-10 07:04:13 UTC
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.
Comment 106 Rainer Bielefeld Retired 2012-09-10 07:23:57 UTC
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.
Comment 107 Not Assigned 2012-09-10 08:08:37 UTC
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.
Comment 108 Michael Meeks 2012-09-10 08:19:02 UTC
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.
Comment 109 Michael Meeks 2012-09-10 08:20:22 UTC
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 ? :-)
Comment 110 Michael Meeks 2012-09-10 09:19:30 UTC
Created attachment 66907 [details]
a new patch
Comment 111 Roman Eisele 2012-09-10 09:27:34 UTC
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?
Comment 112 Not Assigned 2012-09-10 09:54:59 UTC
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.
Comment 113 Not Assigned 2012-09-10 10:00:44 UTC
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.
Comment 114 Don't use this account, use tml@iki.fi 2012-09-10 10:25:30 UTC
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.)
Comment 115 Michael Meeks 2012-09-10 10:37:38 UTC
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 :-)
Comment 116 Roman Eisele 2012-09-10 11:19:47 UTC
(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.
Comment 117 Roman Eisele 2012-09-11 16:52:54 UTC
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.
Comment 118 Michael Meeks 2012-09-11 17:09:34 UTC
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 !
Comment 119 Roman Eisele 2012-09-13 13:15:59 UTC
*** Bug 53221 has been marked as a duplicate of this bug. ***
Comment 120 Roman Eisele 2012-09-13 13:30:45 UTC
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.
Comment 121 Roman Eisele 2012-09-14 08:30:16 UTC
*** Bug 33359 has been marked as a duplicate of this bug. ***
Comment 122 Roman Eisele 2012-09-24 16:00:51 UTC
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!
Comment 123 Roman Eisele 2012-10-03 11:32:54 UTC
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! ;-)