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



On 26Jul2001 05:45PM (-0600), Dan Hensley wrote:
> 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.
> 
> 

This looks like the problem I just fixed last night on the gnome-vfs-1
branch of gnome-vfs. Can you update to the latest on the branch,
rebuild gnome-vfs and see if you still have the problem?

Regards,

Maciej


> 
> #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
> 
 




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]