Re: [Nautilus-list] Nautilus News crashes pretty frequently

[Dan Hensley <dan hensley home com>]

On 26 Jul 2001 05:19:14 -0700, Maciej Stachowiak wrote:
> On 23Jul2001 01:54PM (-0600), Dan Hensley wrote:
> > It crashed on me again just now.  It crashes fairly frequently, but
> > unfortunately whenever it does bug-buddy can't come up with a backtrace.
> > Has anyone else noticed its instability (it's always been unstable for
> > me)?  I guess I can try running nautilus-news in gdb whenever I launch
> > Nautilus, but the crashes are pretty unpredictable.
> > 
> 
> Whoops, I ran under the debugger some more and it looks like there are
> still some crashes. 
> 
> 
> Received Segmentation fault in LWP 3105 while waiting for SIGSTOP.
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 987076 (LWP 23189)]
> 0x409adbe1 in __libc_free (mem=0x40c70530) at malloc.c:3033
> 3033	malloc.c: No such file or directory.
> (gdb) bt
> #0  0x409adbe1 in __libc_free (mem=0x40c70530) at malloc.c:3033
> #1  0x408ab943 in g_free (mem=0x40c00000) at gmem.c:411
> #2  0x40ad6f97 in destroy_thread_state (state=0x40c70530)
>     at gnome-vfs-thread-pool.c:97
> #3  0x40ad7127 in thread_entry (cast_to_state=0x40c70530)
>     at gnome-vfs-thread-pool.c:184
> #4  0x40165d60 in pthread_start_thread_event (arg=0x473ffc00) at manager.c:274
> (gdb) frame 2
> #2  0x40ad6f97 in destroy_thread_state (state=0x40c70530)
>     at gnome-vfs-thread-pool.c:97
> (gdb) p state
> $42 = (struct {...} *) 0x40c70530
> (gdb) p *state
> $43 = {thread_id = 0, waiting_for_work_lock = {__m_reserved = 0, 
>     __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, 
>       __spinlock = 0}}, waiting_for_work_lock_condition = {__c_lock = {
>       __status = 0, __spinlock = 0}, __c_waiting = 0x0}, entry_point = 0, 
>   entry_data = 0x0, exit_requested = 0}
> 
> 
> 
> This kind of smells of a double-free or the like so I'll try leaving
> it running overnight under gdb with MALLOC_CHECK_=2 set and see if that
> sheds light on the matter.
> 
> (This crash seems to take longer to manifest than the other one in the
> http code).
> 
>  - Maciej

Maciej,
	I let nautilus-news run in gdb this afternoon, and sure enough it
crashed.  Here's the backtrace I got.  Hopefully it helps.  I'll also
try to submit a bugzilla report this evening about it.



#0  flush (socket_buffer=0x20) at gnome-vfs-socket-buffer.c:221
#1  0x405f8314 in gnome_vfs_socket_buffer_destroy (buffer=0x20,
close_socket=1)
    at gnome-vfs-socket-buffer.c:83
#2  0x40b0cdcf in make_request (handle_return=0xbf7ffa34, uri=0x8131230,
    method=0x40b113bd "GET", data=0x0, extra_headers=0x0,
context=0x811c3b0)
    at http-method.c:1375
#3  0x40b0cf00 in do_open (method=0x40b13320, method_handle=0xbf7ffa74, 
    uri=0x8131230, mode=GNOME_VFS_OPEN_READ, context=0x811c3b0)
    at http-method.c:1422
#4  0x405e7493 in gnome_vfs_open_uri_cancellable (handle=0xbf7ffaa4, 
    uri=0x8131230, open_mode=GNOME_VFS_OPEN_READ, context=0x811c3b0)
    at gnome-vfs-cancellable-ops.c:54
#5  0x40af108f in execute_open (job=0x81138c0) at gnome-vfs-job.c:940
#6  0x40af1e59 in gnome_vfs_job_execute (job=0x81138c0) at
gnome-vfs-job.c:1564
#7  0x40aefb9e in thread_routine (data=0x15) at gnome-vfs-job-slave.c:66
#8  0x40aee028 in thread_entry (cast_to_state=0x8108c08)
    at gnome-vfs-thread-pool.c:174
#9  0x408d2f54 in pthread_start_thread_event (arg=0xbf7ffc00) at
manager.c:262