GNOME Bugzilla – Bug 387960
Calls to text.getAttributeRun cause gedit to crash when running with Orca
Last modified: 2007-01-02 21:35:08 UTC
The at-spi documentation states that text.getAttributeRun() should now be used in preference to text.getAttributes(). Unfortunately when we tried to use this with Orca it crashed the running application. A typical stack trace for gedit looks like: Distribution: Ubuntu 6.10 (edgy) Gnome Release: 2.16.1 2006-10-02 (Ubuntu) BugBuddy Version: 2.16.0 Memory status: size: 171798528 vsize: 171798528 resident: 27844608 share: 15953920 rss: 27844608 rss_rlim: -1 CPU usage: start_time: 1166634834 rtime: 102 utime: 90 stime: 12 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/usr/bin/gedit' (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 47952112387536 (LWP 8570)] (no debugging symbols found) ... (no debugging symbols found) 0x00002b9cb302beb5 in waitpid () from /lib/libpthread.so.0
+ Trace 95715
Thread 1 (Thread 47952112387536 (LWP 8570))
I will attach a simple standalone Python script that can be used to reproduce the problem.
Created attachment 78701 [details] Standalone Python script that can be used to reproduce the problem. Bug reproducer for bug #387960. This standalone module talks directly with the AT-SPI Registry via its IDL interfaces. No Orca logic or code is stuck in the middle. To run this module, merely type 'python bug_387960.py' in an xterm. Steps to Reproduce: 1. Run the attached standalone python application in an xterm 2. Run gedit 3. Type in "Some text" (without the double quotes). 4. Press F11. 5. Press F12 to terminate the python application. Results: In the xterm window, you will see all a lot of information about all the text in the gedit application. As it currently stands, gedit will crash if you run the steps above and press F11. If you edit the script, and adjust line 401 from: if True or string == "Some text": to if string == "Some text": and rerun with the steps above, then the text.getAttributeRun() call is successful.
I tried the script. When I ran it, it just print out some application information running on my desktop, and when I started gedit, input "Some text" and press F11, nothing happened. No more output from the script. Did I do something wrong?
When I try to run it, I get an immediate COMM FAILURE and the script exits. Script started on Thu 21 Dec 2006 09:18:49 AM EST ]0;jd@pokey: ~jd@pokey:~$ python bug_387960.py Press F12 to Exit. There are 1 desktops Desktop 0 (name=main) has 12 apps App 0: name=gnome-settings-daemon role=application App 1: name=gnome-session role=application App 2: name=metacity role=application App 3: name=gnome-panel role=application Child 0: name=Bottom Expanded Edge Panel role=frame state=(ENABLED RESIZABLE SENSITIVE SHOWING VISIBLE) Child 1: name=Top Expanded Edge Panel role=frame state=(ENABLED RESIZABLE SENSITIVE SHOWING VISIBLE) App 4: name=gnome-volume-manager role=application App 5: name=nautilus role=application Child 0: name=Desktop role=frame state=(ENABLED SENSITIVE SHOWING VISIBLE) Child 1: name= role=window state=(ENABLED RESIZABLE SENSITIVE SHOWING VISIBLE) Child 2: name= role=window state=(ENABLED RESIZABLE SENSITIVE SHOWING VISIBLE) Child 3: name= role=window state=(ENABLED RESIZABLE SENSITIVE SHOWING VISIBLE) App 6: name=update-notifier role=application App 7: name=gnome-power-manager role=application App 8: name=gnome-cups-icon role=application Traceback (most recent call last):
+ Trace 95965
app = desktop.getChildAtIndex(j) CORBA.COMM_FAILURE ]0;jd@pokey: ~jd@pokey:~$ Script done on Thu 21 Dec 2006 09:18:52 AM EST
Created attachment 79004 [details] New version of the standalone Python script.
Created attachment 79005 [details] Output from running the python script when line 386 is "if True or string == "Some text":"
Created attachment 79006 [details] Output from the script when line 386 is "if string == "Some text":"
Li, my instructions might have been slightly confusing. I suspect you might have been hitting F11 when you had focus in the (inaccessible) xterm window. Joanie, I suspect you had something running on your desktop that the script didn't like. Maybe an application running as root? ... I've rewritten the script to no longer call "printDesktops()" so the latter problem should go away. I've rewritten the instructions as: 1. Run gedit 2. Type in "Some text" (without the double quotes). 3. Run the attached standalone python application in an xterm 4. Give focus to the gedit window and press F11. 5. Press F12 in the gedit window to terminate the python application or Control-C in the xterm window. I've also attached the output from the script; both when causing gedit to crash and a "good" run when the script specifically just looks for the string "Some text". If there is anything else I can do, please let me know. Thanks.
Rich, can you provide a stack trace with debug symbols? (need symbols for at-spi, atk, and gail). Also, are you using HEAD or a very recent at-spi/atk/gail set? A serious issue with getAttributeRun was fixed in CVS HEAD around Dec 16/17 IIRC.
Bill, can you not run the small standalone Python script to reproduce the problem? I spent quite a lot of time generating that. If these sort of scripts aren't useful, then I'll stop creating them. I'm using whatever comes in GNOME 2.16.1 on a Ubuntu Edgy system.
Rich - your python script is very helpful :-), so please don't stop generating such scripts. However the stack traces posted without debug symbols are not useful, so as a general request I would ask that you obtain debug versions of the libraries when investigating bugs. It's standard (gnome) operating procedure to mark bugs without debug symbols in the stack trace as 'needinfo'.
Bill - if you run the Python script I created on your machine (which presumably has the latest atk/gail from CVS HEAD), and you follow the steps provided, do you see gedit crash? If so, then you will surely have the debug symbols you are looking for. This should take you 1-2 minutes. What am I missing? > It's standard (gnome) operating procedure to mark bugs without > debug symbols in the stack trace as 'needinfo'. Interesting. Hmm. So I should mark all of those bugs reported automatically by several Linux distros using bugbuddy, as "needinfo" just because their are no debug symbols in them?
"Interesting. Hmm. So I should mark all of those bugs reported automatically by several Linux distros using bugbuddy, as "needinfo" just because their are no debug symbols in them?" Yep, that's what most maintainers do, if the root cause of the problem isn't obvious from the stripped stack trace. In fact if you look just under the "comment box" in bugzilla while logged in you'll see links including "bad_stacktrace" which, if clicked, will mark the bug NEEDINFO while automatically adding a request for a stack trace with debug symbols. (When reading bug mail I am not normally running debug/unstable/HEAD GNOME so I can't just run your python script and expect to get reasonable results.)
How 'bout this one, Bill? I *just* built the following from CVS HEAD: * atk * gail * at-spi * ORBit2 * gedit ------------------------------------- Distribution: Ubuntu 6.10 (edgy) Gnome Release: 2.16.1 2006-10-02 (Ubuntu) BugBuddy Version: 2.16.0 Memory status: size: 37650432 vsize: 0 resident: 37650432 share: 0 rss: 15310848 rss_rlim: 0 CPU usage: start_time: 1167766093 rtime: 0 utime: 48 stime: 0 cutime:44 cstime: 0 timeout: 4 it_real_value: 0 frequency: 0 Backtrace was generated from '/usr/bin/gedit' Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1225673040 (LWP 8233)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 98804
Thread 1 (Thread -1225673040 (LWP 8233))
Thanks Joanmarie! That was enough to locate the problem. I'll attach a patch.
If you want to fix before I post the patch (just dealing with the cvs->subversion migration changes now), substitute param 'j' for 'i' in text.c line 581.
Created attachment 79212 [details] [review] patch to fix this bug (fix array index).
Thanks Bill. @ Rich and for the purpose of documentation: With your script, I can still crash OOo Writer 2.0.4 on Edgy even with Bill's patch. But it doesn't crash Writer 2.1 (at least not today's developer snapshot).