Re: [Pan-users] speed of "Get new articles"

[Charles Kerr]

On Sat, Nov 30, 2002 at 12:38:25PM +0100, Gert wrote:
> Charles Kerr (address@hidden) wrote:
> > On Wed, Nov 27, 2002 at 10:36:03PM +0100, Gert wrote:
> > > Hi,
> > > 
> > > I have a question. Do you think it is possible to shorten the time pan
> > > spends processing the newsgroup after getting the new headers? I am
> > > subscribed to a binary newsgroup which has about 300.000 articles, and I
> > > just clicked on the get new article headers menu item. It started
> > > downloading, which it finished after a minute of 5, fetching the 90.000
> > > new headers. That was 29 minutes ago (and yes, this problem is common
> > > ;).

> > What does the status bar at the bottom say?
> 
> Nothing at all, the GUI won't update.

What did it last say?

> > Try attaching to the running pan process with gdb and hitting
> > ctrl-c to pause it every few minutes, and get a backtrace.
> > Where is Pan spending its time during these 30 minutes?
> > 
> > It will be practically impossible to fix this without helpers...
> 
> Got one here ;)
> Ok,I just updated my headers, but this time (in gdb) it only took about
> 8 minutes. Main difference is that a lot of articles seemed to be
> missing after I started pan. (My guess is it's a feature, pan removes
> all messages from the window that aren't served by the newsserver? -
> good feature anyways).
> I did some backtraces during the CPU cycles, and continued to get traces
> like:
> 
> #0  0x40524991 in nanosleep () from /lib/libc.so.6
> #1  0x404787d2 in __pthread_timedsuspend_new () from /lib/libpthread.so.0
> #2  0x40475286 in pthread_cond_timedwait_relative () from /lib/libpthread.so.0
> #3  0x40475408 in pthread_cond_timedwait () from /lib/libpthread.so.0
> #4  0x4046b7ab in _init () from /usr/lib/libgthread-2.0.so.0
> #5  0x0807efb0 in gtk_widget_grab_focus ()
> #6  0x4038d1d0 in g_static_private_free () from /usr/lib/libglib-2.0.so.0
> #7  0x40475fa5 in pthread_start_thread () from /lib/libpthread.so.0
> #8  0x40475fed in pthread_start_thread_event () from /lib/libpthread.so.0
> 
> Which I thing is just a worker thread. A backtrace on thread #1 (gdb
> cmd "t 1") resulted in the following backtrace:

Best to get backtraces on _all_ the threads.
See http://pan.rebelbase.com/bugs/ for instructions.

> #0  0x404f88dd in memmove () from /lib/libc.so.6
> #1  0x40364539 in g_ptr_array_remove_index () from /usr/lib/libglib-2.0.so.0
> #2  0x40364641 in g_ptr_array_remove () from /usr/lib/libglib-2.0.so.0
> #3  0x0805740a in gtk_widget_grab_focus ()
> #4  0x08065a4c in gtk_widget_grab_focus ()
> #5  0x0808b449 in gtk_widget_grab_focus ()
> #6  0x40379f98 in g_main_context_wakeup () from /usr/lib/libglib-2.0.so.0
> #7  0x40377a19 in g_get_current_time () from /usr/lib/libglib-2.0.so.0
> #8  0x40378837 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
> #9  0x40378c13 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
> #10 0x403792ef in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
> #11 0x400d000f in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
> #12 0x08074031 in gtk_widget_grab_focus ()
> #13 0x4049d0bf in __libc_start_main () from /lib/libc.so.6
> 
> Perhaps this suggests a gtk bug? Do I even have the right thread (24 of
> them are running or so)? My experience with gdb-ing threaded programs is
> limited (make it zero ;)...
> 
> Hope it helps?

Hmm, it's a start, but doesn't give much on its own, sorry.
There are two things we could try:

(1) get backtraces on all threads every minute or so, or

(2) run with --debug and watch what scrolls by in the console during
    these long periods of Pan freezing.  

The second is probably the faster choice....