GNOME Bugzilla – Bug 168161
Nautilus crashes when using GOK
Last modified: 2010-07-06 21:10:27 UTC
Distribution/Version: suse LD1.0 Nautilus version 2.6.1 and GOK version 0.12.4 The steps for recreating the bug: * Launch GOK * Launch This Computer from the bottom panel (Launch Menu) * GOK -> UI Grab -> Icon View -> Documents * GOK opens a window with two options. * Click on open first and then click on Menu. * Nautilus crashes
Created attachment 37780 [details] Stack trace of Nautilus as it crashes
A quick look at the stack trace shows that the boundary type is incorrect. Transferring to at-spi for further evaluation.
by the time impl_getTextAtOffset gets the data, the params are already garbage. Looks like bad demarshalling...
I don't believe that this is an at-spi bug.
I had a look at bug to see if there is anything wrong with nautilus. The behavior of GOK looks suspicious in this case. When GOK grabs a folder in icon view, it shows two options: Open and Menu (these are added as actions for NautilusIconCanvasItemClass in nautilus-icon-canvas-item.c file). When Open is selected, nautilus opens the folder in the same window. But GOK does not refresh its window. It de-sensitizes the Open button but still keeps the Menu button sensitive. Actually this Menu button should have been de-sensitized, as the folder it was meant for had been opened. Also, in this case, the nautilus code which takes care of the Menu action returns immediatly when Menu is clicked, as the NautilusIconCanvasItem object instace is NULL. But after this, I am not sure why AtkTextInterface comes into picture where actual crash is found.
problem is that nautilus' atkobject implementation for the object which has just been 'opened' is still 'activatable', i.e. we try to invoke atk_action_do_action() for that object, but it's gone 'out of scope'. The atkobject wrapper should not allow 'do-action' on an object whose data is no longer valid, for instance due to the destruction of the associated widget. It _is_ true that GOK should not continue to expose the 'menu' button as a valid GokButton in this scenario, but apparently GOK isn't getting the necessary notifications to let it know that it needs to rebuild its UI Grab keyboard. THis may be either due to a missing notification in nautilus, or an insufficiently smart gok update, but in either case that is only the "triggering" condition, the root cause is the atkobject/atkaction implementation in the nautilus process attempting to invoke an action on a 'dead' object.
Since presenting this user option to the user is a UI error (gok's), and the end-user can learn to avoid triggering the bug in this specific scenarios (by selecting 'back' and reloading the UI Grab), I am lowering AP priority to '1' from '0' (the highest). It's still an ugly bug, and hints at a memory
oops, meant to say 'hints at a lifecycle problem in nautilus' AtkObjects'.
The crash can also be simulated in the following way: 1. Invoke nautilus and gok. 2. Click on the 'UI Grab' button in gok & then click on the 'Icon View' button. 3. The folders/files will be listed in gok. 4. Select a folder with many files (make sure scrollbar appears in the nautilus window. Its required to see the problem) 5. Gok will now have 'Back', 'Menu' and 'Open' buttons. 6. Click on the 'Open' button in gok. Nautilus will crash.
Created attachment 39007 [details] [review] Proposed patch The patch introduces a check to make sure that get_simple_text (eel-accessibility.c) is called with a valid accessible object.
Committed on both branches - Thanks.
Changing component as a part of ongoing reorganisation work.