Created attachment 118624 [details] accessible-event listener: soffice-events.py Steps to reproduce: 1. Launch the accessible event listener in a terminal 2. Open the attached test case Expected result: Calc wouldn't crash. Actual result: Calc crashes fairly often. There seems to be a timing issue. In terms of real-world use, if you launch the document with an assistive technology like Orca running and you do not press any arrow keys immediately, Calc doesn't crash. As a result, the event listener is synthesizing several up and down arrow press and releases as soon as the frame becomes active. This seems to increase the likelihood of reproducibility. The Orca user who reported this issue indicated that having Thunderbird running helps make the crash occur. While I've not seen any difference in that regard, I have found that running LibreOffice in gdb greatly improves the changes you'll get the crash. That said, if the crash doesn't happen, leave the event listener running, quit Calc, and re-open the attached test case. I've been getting the crash within 3 tries without gdb, and it reliably crashes every time for me when run in gdb.
Created attachment 118625 [details] Calc document: test.xlsx
Created attachment 118626 [details] backtrace from gdb
Setting version accordingly to first lines of bt.
On pc Debian x86-64 with master sources updated today (and without accessible option enabled so perhaps it's normal), I get no crash. I got these: 08:33:28 - object:state-changed:active from [frame | ] (1, 0, 0) ^[[1;3A^[[1;3B^[[1;3A^[[1;3B^[[1;3A^[[1;3B08:34:03 - object:active-descendant-changed from [table | Feuille 37] (8202, 0, [table cell | K9]) 08:34:03 - object:state-changed:active from [frame | ] (1, 0, 0) 08:34:03 - object:active-descendant-changed from [table | Feuille 37] (8202, 0, [table cell | K9]) 08:34:03 - object:active-descendant-changed from [table | Feuille 37] (9226, 0, [table cell | K10]) 08:34:13 - object:state-changed:active from [frame | ] (1, 0, 0) 08:34:13 - object:active-descendant-changed from [table | Feuille 37] (9226, 0, [table cell | K10]) 08:34:13 - object:active-descendant-changed from [table | Feuille 37] (8202, 0, [table cell | K9]) 08:34:13 - object:active-descendant-changed from [table | Feuille 37] (9226, 0, [table cell | K10]) 08:34:13 - object:active-descendant-changed from [table | Feuille 37] (8202, 0, [table cell | K9]) 08:34:14 - object:active-descendant-changed from [table | Feuille 37] (9226, 0, [table cell | K10]) 08:34:14 - object:active-descendant-changed from [table | Feuille 37] (8202, 0, [table cell | K9]) 08:34:14 - object:active-descendant-changed from [table | Feuille 37] (9226, 0, [table cell | K10]) 08:34:20 - object:state-changed:active from [frame | ] (1, 0, 0) 08:34:20 - object:active-descendant-changed from [table | Feuille 37] (9226, 0, [table cell | K10]) 08:34:20 - object:active-descendant-changed from [table | Feuille 37] (8202, 0, [table cell | K9]) 08:34:20 - object:active-descendant-changed from [table | Feuille 37] (9226, 0, [table cell | K10]) 08:34:20 - object:active-descendant-changed from [table | Feuille 37] (8202, 0, [table cell | K9]) 08:34:20 - object:active-descendant-changed from [table | Feuille 37] (9226, 0, [table cell | K10]) 08:34:20 - object:active-descendant-changed from [table | Feuille 37] (8202, 0, [table cell | K9]) 08:34:20 - object:active-descendant-changed from [table | Feuille 37] (9226, 0, [table cell | K10]) 08:34:24 - object:active-descendant-changed from [table | Feuille 6] (1033, 0, [table cell | J2]) 08:34:26 - object:active-descendant-changed from [table | Feuille 8] (1033, 0, [table cell | J2])
On pc Debian x86-64 with master sources updated yesterday, I don't reproduce this. I enabled Accessibility in Gnome (+ restarted laptop to be sure it's taken into account). I launched the script in a term and in another term, I use make debugrun (so gdb is launched) and opened several times the xlsx. Here is the beginning of the trace I got: /usr/lib/python3/dist-packages/pyatspi/__init__.py:17: PyGIWarning: Atspi was imported without specifying a version first. Use gi.require_version('Atspi', '2.0') before import to ensure that the right version gets loaded. from gi.repository import Atspi ** (process:2436): WARNING **: AT-SPI: Error in GetItems, sender=(null), error=Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. 12:12:15 - object:active-descendant-changed from [table | Sheet 37] (8202, 0, [DEAD]) Exception getting attributes for [DEAD] 12:12:16 - object:state-changed:active from [DEAD] (1, 0, 0) 12:12:16 - object:active-descendant-changed from [table | Sheet 37] (8202, 0, [DEAD]) Exception getting attributes for [DEAD] 12:12:16 - object:state-changed:active from [DEAD] (1, 0, 0) 12:12:16 - object:active-descendant-changed from [table | Sheet 37] (8202, 0, [DEAD]) Exception getting attributes for [DEAD] 12:12:23 - object:state-changed:active from [frame | test.xlsx - LibreOfficeDev Calc 5.2 [6c2a9102eeb4d3de6a64780eb2b97415b15ce4a9]] (1, 0, 0) ^[[A^[[B^[[A^[[B^[[A^[[B12:12:23 - object:active-descendant-changed from [table | Sheet 37] (8202, 0, [DEAD]) Exception getting attributes for [DEAD] 12:12:40 - object:state-changed:active from [frame | test.xlsx - LibreOfficeDev Calc 5.2 [6c2a9102eeb4d3de6a64780eb2b97415b15ce4a9]] (1, 0, 0) 12:12:40 - object:active-descendant-changed from [table | Sheet 37] (8202, 0, [table cell | K9]) 12:12:40 - object:active-descendant-changed from [table | Sheet 37] (7178, 0, [table cell | K8]) 12:12:40 - object:active-descendant-changed from [table | Sheet 37] (8202, 0, [table cell | K9]) 12:12:40 - object:active-descendant-changed from [table | Sheet 37] (7178, 0, [table cell | K8]) Do you still reproduce this with recent LO version (last stable one is 5.0.4)? Or perhaps I missed something?
Hi, In my Ubuntu 14.04 system now I using Orca master branch version. My system from Libreoffice PPA repository updated the Libreoffice version with 5.0.4.2 version. I launched now seven time in a Terminal window with Libreoffice calc the attached .xlsx document and Libreoffice doesn't crashed me. Switching between sheet pages works perfect too. Joanie, you confirming this result? Attila
Per comment 6, what is the status? Set to NEEDINFO. Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away.
Created attachment 123165 [details] backtrace from 5.1.1 Same steps to reproduce, same reliable segfault. Now using v5.1.1.
(In reply to Beluga from comment #7) > Per comment 6, what is the status? > > Set to NEEDINFO. > Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED > WORKSFORME, if the problem went away. Done.
Jacobo: When you get a chance could you please look into this? I have a user who is getting a reliable crash just from doing the following: > 1. Start LibreOffice Calc with running Orca. > 2. In A1 enter the number 2. > 3. In A2 enter the number 3. > 4. In A3 enter =sum(a1,a2) and press Enter or Tab. > At this point LibreOffice becomes unresponsive and crashes. That I myself cannot reproduce. But the segfault is happening at the same place: Program received signal SIGSEGV, Segmentation fault. (anonymous namespace)::IMPL_RTL_ACQUIRE ( pThis=0xad198670 <vtable for ScFormulaCell+8>) at /usr/src/debug/libreoffice-5.0.5.2/sal/rtl/strtmpl.cxx:1199 1199 osl_atomic_increment( &((pThis)->refCount) ); And for that user, it makes Calc largely unusable. :( Thanks!
I'm able to reproduce the issue in LibreOffice 5.1.2. 1) Launch Orca 2) Open the attached spreadsheet LibreOffice calc crashes immediately. It seems that we should make the bug as critical because it makes LibreOffice calc unusable.
Investigating.
dbgutil build, a11y enbabled, Orca not, soffice started, script run, attached gdb to soffice process and with a procedure mentioned in the original post (wildly hit several cursor keys while the document loads ;) I could reproduce after the document loaded fine the first time without hitting cursor keys. Having found the cause made me wonder why that wasn't hit more often even without cursor key movement..
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3a767d91bfa70af4303b905cefa038181d56cc9a Resolves: tdf#94146 a11y crash, obtain formula using the correct pointer It will be available in 5.2.0. 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.
Pending review https://gerrit.libreoffice.org/24652 for 5-1
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=84c6afa54def64d1ab548378caccde93b563d0f2&h=libreoffice-5-1 Resolves: tdf#94146 a11y crash, obtain formula using the correct pointer It will be available in 5.1.4. 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.
Dear all, I confirm, the bug has been correctly fixed. Thanks a lot to Eike Rathke! Best regards.