[Pan-users] Re: freeze, high CPU getting new headers

[walt]

On Tue, 05 Aug 2008 05:46:32 +0000, Duncan wrote:

> ...
> GL's suggestion, I think, was that it was just taking the time to sort
> all those headers, and there wasn't a lot that could be done about it. 
> I don't believe that's the case, because it's not behaving that way for
> everyone, and where it is, it's fairly recent -- it was working fine
> some months ago.

And the 32-bit version works as expected, per David.  (I think he
meant on the same hardware, but I'm not sure.)

If you open the event log while fetching headers you will see that
pan stops every 10 seconds to rethread.  On my machine, with my DSL
connection, pan has to readthread about 50-80 articles every 10
seconds, which is trivial and instantaneous.  Now if I had a cable
connection, which is allegedly 5-10x faster, pan would need to stop
and rethread several hundred articles instead of 80.  That may not
scale very well, but I can't imagine that it would take very long.

> ...
> Of course, the above assumes you know how to have gdb suspend the run
> (the interrupt does that) to do the bt, then resume it, then suspend it
> again 30 seconds later, keeping both backtraces (plus a few more in the
> suspend/bt/resume/wait30 cycle) to compare them later.  I'm not a gdb
> guru, so I'd be feeling my way on that too...

gdb has a pretty good help facility built in.  From it's command prompt
type 'help' to see the top-level menu, and then 'help running', for
example, to find the 'run' and 'continue' commands, which do exactly
what you suggested above.  These can be shortened to 'r' and 'c' to
save keystrokes.  I got a lot of practice when I was working on the
incorrect display of multi-part jpegs a few months ago.  One nice thing
about running gentoo is that you can trivially build debugging symbols
into libraries like gtk and glib, which is important for bug hunting
in a gtk program like pan.