Steps to reproduce: 1. Get Accerciser (http://live.gnome.org/Accerciser), also enable AT support for your session. 2. Open the test case in LibreOffice. 3. Launch Accerciser, select LibreOffice in the tree on the left. Then use the Event Monitor to enable listening for object:children-changed:add events for the selected application. 4. Return focus to the document and arrow up and down rapidly. Expected results: LibreOffice would not crash. Actual results: LibreOffice crashes reliably. The impact of this is that Orca users are seeing frequent crashes when working on documents, especially those with bullets/numbers. [1] On a bright note, I'm not seeing this issue in the OOo 3.4 Dev builds so hopefully whatever the fix is, it is one you can easily incorporate. [1] https://bugzilla.gnome.org/show_bug.cgi?id=635604
I didn't reproduce this either on LibreOffice 3.3 beta3 / SLED11 sp1. The event monitor keeps logging the following without a crash after dozens of time s up/down arrow pressing. Please feel free to re-open it if the problem is still there in the latest build. object:children-changed:add(0, 0, [push button | Bullets On/Off]) source: [tool bar | Bullets and Numbering] application: [application | soffice] object:children-changed:add(1, 0, [push button | Numbering On/Off]) source: [tool bar | Bullets and Numbering] application: [application | soffice] object:children-changed:add(3, 0, [push button | Numbering Off]) source: [tool bar | Bullets and Numbering] application: [application | soffice] object:children-changed:add(5, 0, [push button | Promote One Level]) source: [tool bar | Bullets and Numbering] application: [application | soffice] object:children-changed:add(6, 0, [push button | Demote One Level]) source: [tool bar | Bullets and Numbering] application: [application | soffice] object:children-changed:add(7, 0, [push button | Promote One Level With Subpoints]) source: [tool bar | Bullets and Numbering] application: [application | soffice] object:children-changed:add(8, 0, [push button | Demote One Level With Subpoints]) source: [tool bar | Bullets and Numbering] application: [application | soffice] object:children-changed:add(10, 0, [push button | Insert Unnumbered Entry]) source: [tool bar | Bullets and Numbering]
Created attachment 40674 [details] backtrace I can still reproduce it. I just built LibreOffice from git. It claims to be this version: LibreOffice 3.3.0 OOO330m17 (Build:1) libreoffice-build 3.2.99.3 Backtrace from segfault attached. Mind you, I had to arrow around *a bunch*. I think it might be timing related. Could you please take another look? Thanks!
From the back trace it looks like you're starting to destroy an accessible object, while doing that you do something that causes you to enter the main loop where you answer a request to find the name of the accessible you just started destroying. So my gues is that either you arent checking if the object is being destroyed before trying to get the name, or your check isnt working. I tried to take a quick look to see if I could understand the code in VCLXAccessibleToolBoxItem but didn't have much luck.
Last stable version of LO is 3.4.5. Soon, there'll be 3.5.0 (3.5.0 rc3 has been released) Could you try to reproduce the problem with LO versions quoted (and perhaps the last version of Accerciser) and, if it's still there get a new backtrace ?
So there's good news and possibly bad news. The good news is that in my environment, which is unstable everything (Fedora Rawhide plus a bunch of GNOME packages built from master) I cannot reproduce this problem -- as a crasher, anyway. By which I mean: Accerciser (built from master) still shows plenty of instances of "dead" accessibles when following the steps in the opening report. And those "dead" accessibles should not be there. They are, I'm almost certain, the source of the crashes. Which brings me to: The bad news, depending upon your perspective, is that I don't believe you have fixed anything on the LibreOffice side. I think the reason I am no longer seeing the crash resulting from the dead accessibles is that there have been a number of changes in AT-SPI2 basically added to detect things like this bug and take measures to try not to trigger a crash. Long way of saying that users who need accessibility support, are not using the very latest accessibility libraries, but are using LibreOffice 3.5 very well may still see this crash. :( With this in mind feel free to do what you'd like with respect to this bug.
So - I struck upon this while looking for a rather more serious Mac a11y crasher, hoping it would make LibreOffice crash so I could mend it :-) The trace is useful, but would have been fantastically more so with debugging symbols, so we could see if it was the same Window being destructed that got re-entered during that destruction :-) Anyhow - thanks !