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

[walt]

On Wed, 06 Aug 2008 17:06:30 +0000, Duncan wrote:

> Rhialto <address@hidden> posted
> address@hidden, excerpted below, on 
> Wed, 06 Aug 2008 09:38:30 +0200:
> 
>> On Wed 06 Aug 2008 at 01:24:11 +0000, walt wrote:
>>> Your 'stuck' traces show an infinite loop of file read and writes, and
>>> the output includes the names ROLE_TOOL_BAR and ROLE_TOOL_TIP over and
>>> over. It's easy to figure out that these symbols belong to atk
>>> (accessibility tool kit), and that's no surprise because pan is linked
>>> to libatk.
>> 
>> I thought they may be X11 connection data?
> 
> The URL for the straces again (please keep this bit as long as referring
> to them):    http://www.xs4all.nl/~benscho9/pan/

<much snippage>

> So it reads in a bunch of headers, then stalls, apparently doing no
> system calls except for what appears to be updating X.  What it's doing
> in the the background isn't obvious from the strace since it's only a
> system-call trace, after all, but the reasonable assumption is that it's
> digesting the data it got, figuring out where to plug it into the
> existing linked-list of posts as threaded, etc...

I agree with everything above except possibly the updating X part, which
I'm still thinking about.  The bug, as I understand it, is that the pan
gui completely freezes -- and that should include any tooltips (guys, do
the tooltips keep working during the freeze?).  So what is it exactly
that these signals(?) are doing while the gui is frozen?

I must admit that David's gdb trace does look like a program that's at
least doing a good imitation of useful work, but there's no way to know
how fast pan is doing it.  His trace does mention values being optimized
out, so I wonder if this problem has something to do with the compiler
flags used during compilation.  Dunno, but gcc-64 might have issues there
that gcc-32 doesn't.