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 74120 - apparent crash during frequent file changing/icon redrawing
apparent crash during frequent file changing/icon redrawing
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: general
unspecified
Other other
: High critical
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 66847 74378 80112 81291 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-03-10 05:26 UTC by Luis Villa
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: Old
GNOME version: ---


Attachments
Stack trace from the crash (12.05 KB, text/plain)
2002-05-29 15:15 UTC, aaron
Details

Description Luis Villa 2002-03-10 05:30:41 UTC
Package: nautilus
Severity: critical
Version: 1.1.8
Synopsis: apparent crash during frequent file changing
Bugzilla-Product: nautilus
Bugzilla-Component: general
BugBuddy-GnomeVersion: 2.0 (1.112.1)

Description:
Description of Problem:
While editing a text file on my desktop via emacs over and over again,
nautilus crashed spontaneously. Can't reproduce. :/ Assume it may have
happened during re-rendering of the file icon, but there is no way to be
sure.



Debugging Information:

[New Thread 1024 (LWP 7903)]
[New Thread 2049 (LWP 7917)]
[New Thread 1026 (LWP 7918)]
[New Thread 2051 (LWP 7919)]
[New Thread 3076 (LWP 7920)]
0x40946e29 in __wait4 () from /lib/libc.so.6

Thread 1 (Thread 1024 (LWP 7903))

  • #0 __wait4
    from /lib/libc.so.6
  • #1 __DTOR_END__
    from /lib/libc.so.6
  • #2 waitpid
    at wrapsyscall.c line 172
  • #3 libgnomeui_segv_handle
    at gnome-ui-init.c line 598
  • #4 pthread_sighandler
    at signals.c line 97
  • #5 <signal handler called>
  • #6 g_logv
  • #7 g_log
  • #8 add_to_link_hash_table_list
    at nautilus-file.c line 212
  • #9 modify_link_hash_table
    at nautilus-file.c line 203
  • #10 add_to_link_hash_table
    at nautilus-file.c line 219
  • #11 update_info_internal
    at nautilus-file.c line 1225
  • #12 update_info_and_name
    at nautilus-file.c line 1236
  • #13 nautilus_file_new_from_info
    at nautilus-file.c line 257
  • #14 dequeue_pending_idle_callback
    at nautilus-directory-async.c line 849
  • #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 915
  • #21 main
    at nautilus-main.c line 265
  • #22 __libc_start_main
    at ../sysdeps/generic/libc-start.c line 129
  • #0 __wait4
    from /lib/libc.so.6
  • #0 __wait4
    from /lib/libc.so.6
  • #1 __DTOR_END__
    from /lib/libc.so.6
  • #2 waitpid
    at wrapsyscall.c line 172
  • #3 libgnomeui_segv_handle
    at gnome-ui-init.c line 598
  • #4 pthread_sighandler
    at signals.c line 97
  • #5 <signal handler called>
  • #6 g_logv




------- Bug moved to this database by unknown@bugzilla.gnome.org 2002-03-10 00:30 -------

Unknown version 1.1.x in product nautilus. Setting version to the default, "unspecified".
Reassigning to the default owner of the component, nautilus-maint@bugzilla.gnome.org.

Comment 1 Luis Villa 2002-03-12 22:53:20 UTC
*** Bug 74378 has been marked as a duplicate of this bug. ***
Comment 2 Luis Villa 2002-03-12 22:54:19 UTC
Other bug has identical trace and same problem- emacs + editing file
on desktop.
Comment 3 aaron 2002-03-13 00:47:22 UTC
This used to happen under Nautilus1, as well, although I assumed that
the periodic flashing of my desktop, sudden HD grinding, and pegged
CPU performance as Nautilus restarted was just part of the way
Nautilus changed icons. This time, though, it doesn't restart when it
crashes, and gives me a crash-dialog, so I know it's a bug and not
just a poorly implemented feature.

Comment 4 Luis Villa 2002-03-13 02:45:17 UTC
Hrm. And now neither of us can duplicate the problem. :/ Closing until
we can.
Comment 5 aaron 2002-03-15 00:57:04 UTC
Happening in nautilus2-1.1.9.0.200203140655-snap.ximian.1
Comment 6 aaron 2002-03-28 21:03:42 UTC
Still happens in 
nautilus2-1.1.11.0.200203280358-0.snap.ximian.1
Comment 7 Luis Villa 2002-03-29 21:58:51 UTC
cc'ing jacob for his consideration later.
Comment 8 Heath Harrelson 2002-04-28 22:52:25 UTC
*** Bug 80112 has been marked as a duplicate of this bug. ***
Comment 9 Luis Villa 2002-05-01 10:07:42 UTC
Can you take a look, Damon? Thanks.
Comment 10 John Fleck 2002-05-10 02:47:35 UTC
*** Bug 81291 has been marked as a duplicate of this bug. ***
Comment 11 Damon Chaplin 2002-05-16 22:22:08 UTC
I haven't managed to reproduce this yet. If anyone knows a reliable
way of doing that please add a comment.

Do you have the desktop set up to show the saved session files or not?
Comment 12 aaron 2002-05-16 23:18:46 UTC
I do not have any . or ~ files displayed, but those are the only
options.  Emacs does create visible # files in my desktop. 

I have nautilus set to draw my desktop and -- this may be relevant-- I
also have my homedir set as my desktop. Not sure why it would be, but
it's possible.
Comment 13 Luis Villa 2002-05-22 22:19:31 UTC
cc'ing jacob since he was seeing this too.
Comment 14 lukeh 2002-05-27 18:21:45 UTC
*** Bug 66847 has been marked as a duplicate of this bug. ***
Comment 15 Luis Villa 2002-05-29 05:42:32 UTC
Is anyone still seeing this? I'm not, though I haven't done the exact
steps in a while to test it.
Comment 16 aaron 2002-05-29 15:15:40 UTC
Created attachment 8818 [details]
Stack trace from the crash
Comment 17 aaron 2002-05-29 15:16:01 UTC
Yeah, I'm still getting it.  It takes longer to make it happen though.
Comment 18 Michael Meeks 2002-05-29 16:38:53 UTC
ok, trivially repeatable, essentialy the problem is not removing the
file from the link hash in nautilus_file_mark_gone, will commit shortly.
Comment 19 Damon Chaplin 2002-05-29 18:34:19 UTC
Yes, I spotted this last night as well.

The links hash table is broken as well. When inserting it just uses
the symlink name, but when looking up in it it uses the full uri.

I suppose I'll add another bug about that.