After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 78948 - Nautilus crashes when I hit ESC on the "Error while moving" dialog
Nautilus crashes when I hit ESC on the "Error while moving" dialog
Status: VERIFIED FIXED
Product: nautilus
Classification: Core
Component: File and Folder Operations
0.x.x [obsolete]
Other Linux
: High critical
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2002-04-17 13:37 UTC by Anand
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
handle GTK_RESPONSE_DELETE_EVENT (1.46 KB, patch)
2002-06-04 22:24 UTC, Dave Camp
none Details | Review

Description Anand 2002-04-17 13:37:10 UTC
Gnome 2.0 was built on the 15h April from CVS.

Description:
I try to move a file/folder for which I do not have write permission, 
using right click. I then hit the ESC key on the dialog which pops up. 
Nautilus crashes.

Steps:
1) Switch over to icon view. Browse to, say, "/etc" folder.
2) Right click on a file/folder (E.g. passwd), drag the item and drop it 
on the desktop or on another nautilus window.
3) Choose the 'Move' option in the popup menu.
4) The "Error while moving" dialog appears.
5) Hit the ESC key and Nautilus crashes.

Debugging info:
stack trace attached below.

[New Thread 1024 (LWP 2719)]
[New Thread 2049 (LWP 2720)]
[New Thread 1026 (LWP 2721)]
[New Thread 2051 (LWP 2722)]
0x40cfb519 in __wait4 () from /lib/i686/libc.so.6
  • #0 __wait4
    from /lib/i686/libc.so.6
  • #1 __DTOR_END__
    from /lib/i686/libc.so.6
  • #2 waitpid
    at wrapsyscall.c line 172
  • #3 libgnomeui_segv_handle
    at gnome-ui-init.c line 593
  • #4 pthread_sighandler
    at signals.c line 97
  • #5 <signal handler called>
  • #6 __kill
    from /lib/i686/libc.so.6
  • #7 raise
    at signals.c line 65
  • #8 abort
    at ../sysdeps/generic/abort.c line 88
  • #9 g_logv
  • #10 g_log
  • #11 handle_transfer_vfs_error
    at nautilus-file-operations.c line 929
  • #12 update_transfer_callback
    at nautilus-file-operations.c line 1489
  • #13 dispatch_xfer_callback
    at gnome-vfs-job.c line 305
  • #14 dispatch_sync_job_callback
    at gnome-vfs-job.c line 439
  • #15 g_idle_dispatch
    at gmain.c line 3129
  • #16 g_main_dispatch
    at gmain.c line 1617
  • #17 g_main_context_dispatch
    at gmain.c line 2161
  • #18 g_main_context_iterate
    at gmain.c line 2242
  • #19 g_main_loop_run
    at gmain.c line 2462
  • #20 gtk_main
    at gtkmain.c line 912
  • #21 main
    at nautilus-main.c line 263
  • #22 __libc_start_main
    at ../sysdeps/generic/libc-start.c line 129
  • #0 __wait4
    from /lib/i686/libc.so.6
  • #1 __DTOR_END__
    from /lib/i686/libc.so.6
  • #2 waitpid
    at wrapsyscall.c line 172
  • #3 libgnomeui_segv_handle
    at gnome-ui-init.c line 593
  • #4 pthread_sighandler
    at signals.c line 97
  • #5 <signal handler called>
  • #6 __kill
    from /lib/i686/libc.so.6
  • #7 raise
    at signals.c line 65

Comment 1 Anders Carlsson 2002-04-19 00:11:11 UTC
I just fixed this in CVS.
Comment 2 Anand 2002-06-04 15:37:47 UTC
Anders: Seeing this crash again in a slightly different scenario 
(i've got an identical stack trace). 

Ways to reproduce.
1) Copy some files/folders (say 15-20), paste them onto a different 
location.
2) Interrupt the copying process, by pressing Cancel.
3) Resume copying once again, by pasting into the same folder again, 
to be prompted for item replace. 
4) Press ESC. And the crash occurs.

Attaching a fresh copy of the stack trace.

[New Thread 1024 (LWP 4532)]
[New Thread 2049 (LWP 4535)]
[New Thread 1026 (LWP 4536)]
[New Thread 2051 (LWP 4537)]
[New Thread 3076 (LWP 4538)]
[New Thread 4101 (LWP 4539)]
[New Thread 5126 (LWP 4540)]
0x40d52519 in __wait4 () from /lib/i686/libc.so.6
  • #0 __wait4
    from /lib/i686/libc.so.6
  • #1 __DTOR_END__
    from /lib/i686/libc.so.6
  • #2 waitpid
    at wrapsyscall.c line 172
  • #3 libgnomeui_segv_handle
    at gnome-ui- init.c line 592
  • #4 pthread_sighandler
    at signals.c line 97
  • #5 <signal handler called>
  • #6 __kill
    from /lib/i686/libc.so.6
  • #7 raise
    at signals.c line 65
  • #8 abort
    at ../sysdeps/generic/abort.c line 88
  • #9 g_logv
  • #10 g_log
  • #11 handle_transfer_overwrite
    at nautilus-file-operations.c line 1068
  • #12 update_transfer_callback
    at nautilus-file-operations.c line 1492
  • #13 dispatch_xfer_callback
    at gnome-vfs-job.c line 305
  • #14 dispatch_sync_job_callback
    at gnome-vfs-job.c line 439
  • #15 g_idle_dispatch
    at gmain.c line 3129
  • #16 g_main_dispatch
    at gmain.c line 1617
  • #17 g_main_context_dispatch
    at gmain.c line 2161
  • #18 g_main_context_iterate
    at gmain.c line 2242
  • #19 g_main_loop_run
    at gmain.c line 2462
  • #20 gtk_main
    at gtkmain.c line 922
  • #21 main
    at nautilus- main.c line 263
  • #22 __libc_start_main
    at ../sysdeps/generic/libc-start.c line 129
  • #0 __wait4
    from /lib/i686/libc.so.6
  • #1 __DTOR_END__
    from /lib/i686/libc.so.6
  • #2 waitpid
    at wrapsyscall.c line 172
  • #3 libgnomeui_segv_handle
    at gnome-ui- init.c line 592
  • #4 pthread_sighandler
    at signals.c line 97
  • #5 <signal handler called>
  • #6 __kill
    from /lib/i686/libc.so.6
  • #7 raise
    at signals.c line 65

Comment 3 Dave Camp 2002-06-04 22:24:33 UTC
Created attachment 8988 [details] [review]
handle GTK_RESPONSE_DELETE_EVENT
Comment 4 Dave Camp 2002-06-04 22:25:55 UTC
GtkDialog handles "delete_event" before eel_run_simple_dialog does, so
eel never has a chance to circumvent delete_event.  This handles the
GTK_RESPONSE_DELETE_EVENT return value of gtk_run_dialog the same way
it handled GTK_RESPONSE_NONE (ie -1).
Comment 5 Alexander Larsson 2002-06-13 07:00:46 UTC
Looks fine. Please commit.
Comment 6 John Fleck 2002-06-13 14:33:31 UTC
Whatever happened to this? Was it committed?
Comment 7 Luis Villa 2002-06-13 14:35:42 UTC
Well, it was only seven hours ago that commit permission was given,
and I guarantee dave hasn't been up for any of those seven hours :) 
Comment 8 John Fleck 2002-06-13 15:30:29 UTC
/me smirks in embarassment, thinking he was dealing with a moldy old bug
Comment 9 Dave Camp 2002-06-13 18:24:33 UTC
Checked in.
Comment 10 Anand 2002-06-25 09:02:38 UTC
Dave: I see that the ESC key no longer works on the 'confirm replace' 
dialog. Is this what should be happening? Or am i seeing something 
wrong? (I have the 21st June sources from CVS)
Comment 11 Dave Camp 2002-06-25 14:06:44 UTC
That is what should be happening.  That code called
eel_simple_dialog_run with an ignore_delete_event argument of FALSE. 
Ignoring the delete_event (which was supposed to ignore esc too)
wasn't working.
Comment 12 Anand 2002-06-27 03:11:16 UTC
Ah okay. 

Closing bug. Thanks :)