GNOME Bugzilla – Bug 517026
crash in Open Folder: Deleting the last file i...
Last modified: 2018-04-14 23:59:16 UTC
Version: 2.20.0 What were you doing when the application crashed? Deleting the last file in a directory while Orca was running. Distribution: Solaris Express Developer Edition 1/08 snv_79b X86 Gnome Release: 2.20.1 2007-11-19 (Sun Microsystems, Inc.) BugBuddy Version: 2.20.1 X Vendor: Sun Microsystems, Inc. X Vendor Release: 10300000 Selinux: No Accessibility: Enabled GTK+ Theme: nimbus Icon Theme: nimbus Memory status: size: 107048960 vsize: 107048960 resident: 32620544 share: 786432 rss: 32620544 rss_rlim: 0 CPU usage: start_time: 0 rtime: 365 utime: 3273025 stime: 377372 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 0 Backtrace was generated from '/usr/bin/nautilus' (no debugging symbols found) sol-thread active. Retry #1: Retry #2: Retry #3: Retry #4: [New LWP 1 ] [New Thread 1 (LWP 1)]
+ Trace 189489
Thread 1 (LWP 1)
Thread 1 (LWP 1 ): #-1 0xcfee3f85 in _waitid () from /lib/libc.so.1 No symbol table info available. #-1 0xcfee3f85 in _waitid () from /lib/libc.so.1
The relevant nautilus settings that differ from the default seem to be this: Edit->Preferences->Behavior: [ ] Ask before emptying the Trash or deleting files [x] Include a Delete command that bypasses Trash View->View as List I then went to a directory and pressed Shift+F10 followed by 'D' to delete each file while Orca was running. On the last file, Nautilus crashed and bug buddy appeared. This looks like it might be a gail issue -- Li, what do you think?
Seems Orca called Accessibility_Table_getRowDescription with row number=-1. I think a check needs to be added in gail or atk. And also we can take a look at Orca's code why the "-1" call happens, what is Orca really want to get?
(In reply to comment #2) > Seems Orca called Accessibility_Table_getRowDescription with row number=-1. I > think a check needs to be added in gail or atk. And also we can take a look at > Orca's code why the "-1" call happens, what is Orca really want to get? > Eeeks. This isn't good. Rich, can you take a look at this (please)? It may be that all we need to do is add checks in default.py:locusOfFocusChanged to make sure the index being passed into getRowDescription and getColumnDescription are >= 0.
Created attachment 105583 [details] Orca debug.out generated whilst testing this. I created a directory called "testarea" and put three empty files in it with: $ mkdir testarea $ touch file1 file2 file3 I then followed the steps in comment #1. I also added some debug print statements to the locusOfFocusChanged() method in default.py in Orca. Orca debug log attached. When I pressed Shift-F10, "d", Tab to delete the last file, we get an "object:active-descendant-changed" at line 2528. This called locusOfFocusChanged (line 2542), and I print the details of the new locus of focus (line 2543): newLocusOfFocus: app.name='nautilus' name='None' role='table cell' state='active defunct enabled focusable focused selectable sensitive showing transient visible' relations='node child of' Further down the locusOfFocusChanged() method there is indeed a call to: desc = table.getRowDescription(newRow) with a row number of -1 (line 2583). But what's more interesting is that one of the states for this new locus of focus is "defunct". We certainly could put in some checks to make sure we aren't trying to get a row description for a row of -1, but wouldn't it be better if locusOfFocusChanged() just returned if the new locus of focus has a "defunct" state?
Oh, I should add at the end there, both Orca and nautilus are non-responsive.
Created attachment 105584 [details] [review] Patch to potentially fix the problem. This patch adds a check to the start of the locusOfFocusChanged() method in default.py to just return if the new locus of focus has a "defunct" state. Seems to work nicely for me. New debug.out to follow.
Created attachment 105585 [details] Orca debug log generated after testing the "defunct" patch. You'll note that for each of the three times that locusOfFocusChanged() is called after we've deleted a file, that the new locus of focus has a "defunct" state (lines 1066, 1823 and 2590).
(In reply to comment #7) > Created an attachment (id=105585) [edit] > Orca debug log generated after testing the "defunct" patch. > > You'll note that for each of the three times that locusOfFocusChanged() > is called after we've deleted a file, that the new locus of focus has > a "defunct" state (lines 1066, 1823 and 2590). > This seems to nicely fix the problem in Orca, so I think you should check that in (thanks!). I think we should still leave this open, however, and in atk for Li as a reminder to add some condition checking. Since we've worked around it, though, we can lower the priority of this bug.
Orca change committed to SVN trunk.
I'd like to downgrade the bug, because there are so many functions that need to add condition check. And actually the crash happens in gtk+, seems they don't have condition check too.
It still breaks for me. I'm using Slackware 12.0, Dropline-Gnome 2.20.0 with latest upgrade to date which includes Nautilus 2.20.0. I am using latest trunk of Orca, at-spi, atk and gail as of 03/17/2008. I do the following and it crashes with complete loss of speech and inability to log off gnome. I have to ctrl-alt-backspace to exit gnome and I then get back in by typing startx from a text console. 1. create a directory in my home folder called test_folder. 2. create several files inside that folder: file1, file2, file3; I used touch command to do this. 3. Navigate with file browser in list view to test_folder. 4. Open test_folder. 5. Start deleting each file one by 1 by pressing shift DEL. I have the full delete turned on in preferences as well as the confirmation prompt. 6. press space bar to confirm each delete. 7. Upon deleting and confirming the final delete (file3), I hear the click from hitting space bar to answer final prompt and I at that point lose speech completely. 8. After this, I cannot logout of gnome. I get as far as hitting space bar on the confirmation dialog to logout (with no speech of course) but it doesn't log me out. I have no idea if there is a hanging prompt or what. I end up using ctrl-alt-backspace to get me out. This has never worked right for me when the folder becomes empty from last deletion. Oh, I should also note that I have the checkbox set for behavior to allow separate windows for each folder in case that matters.
I can not reproduce this on my box. Nautilus didn't crash. Maybe some other application hang? BTW, I have problem to select the last file in the folder, it got the broken line box, but never highlighted. I have to select it by mouse. Is it a known bug?
> BTW, I have problem to select the last file in the folder, it got the broken > line box, but never highlighted. I have to select it by mouse. Is it a known > bug? That means it's focused but not selected. Pressing Control-Space should select it. Steve discussed this on the Orca mailing list. I get the same results as you. See: http://mail.gnome.org/archives/orca-list/2008-March/msg00508.html
I did some more testing and I will elaborate as follows: First test: 1. went into a terminal and went into my test folder and did a "touch file1 file2 file3" to give me 3 files. 2. opened up Nautilus to my home folder and navigated down to test_folder and pressed enter to select it. 3. Arrowed up and down the list to verify file presence and then began deleting with shift DEL and confirming the delete prompt with space bar. 4. after deleting 3rd and final file, lost everything like before. I should note on this last file, I arrowed up and down the list and heard nothing; I usually never do on the single entry like that. I could arrow right and left to hear items in the table that way. Pressing ctrl-space said "Unselected" the first time pressed; second time said "Selected" and kept toggling accordingly. I left it as "Selected" and then did the delete and lost it. Second test: 1. Set everything up like the first time but when I reached the last file, I pressed Shift-DEL and got the dialog; I then alt-tabbed to something else like the terminal or anotherr file browser window or whatever, then alt-tabbed back to this folder with the confirm dialog still sitting there. Then hit space bar to accept and focus remained in the empty folder and I did *NOT* lose Orca.
I did more testing on this with the same configuration in my test_folder. But I repeated the test I most recently did and I lost Orca again. What seems to be more consistent is to alt-tab away from the folder contain a single entry and then come back in and *DO NOT* press any other keys except for the shift-delete key and answer the confirm dialog. If I do it this way, I don't lose speech and I've been able to do this several times in a row. I also did a test this morning where I quit Orca and then deleted the last entry in the folder and then restarted Orca afterwards and all was fine so that tells me that the problem is in Orca for sure. There is obviously a major focus issue here though because each time I delete a file and confirm deletion, speech stops before speaking the current selection and I don't hear anything until I arrow to another file in the list.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new