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

[Duncan]

Matthijs Benschop <address@hidden>
posted address@hidden, excerpted below, on  Mon, 04 Aug 2008
20:46:00 +0000:

> Op Mon, 04 Aug 2008 19:40:40 +0000, schreef walt:
>> 
>> Just occurred to me that I don't use any filters, so the 'apply_filter'
>> step in my case would be a null_op.  What about you (and David)?
> 
> No filters enabled here (unless they're configured somewhere I dont
> know)
> 
> Btw, I verified running my same distro but 32bit version (same
> packages), and no problems at all. Maybe 64bit issue..? Triggered by
> something else in the system (because it ran fine until few months back)

If it's 64-bit specific, it'd seem to be specific to either the 
distribution (patch set) or a specific library version you are running.  
The segfaults also indicate something strange, maybe related, maybe not, 
but I know I don't get them here!

It's also possible it's specific to the gcc and/or its optimizations for 
your distribution @ 64-bit.

> Is the gdb output of any use? I have some more which are a little
> different.

It could be of some use, altho as I said earlier, I definitely don't 
claim to be an expert at this.

You mentioned the main loop.  I think you are interpreting the output 
backwards.  The main loop is what the program is always running.  It'll 
always be the top parent, bottom as listed by a backtrace.  Where it was 
actually executing at the time of the interrupt is at the top of the list.

> ^C
> Program received signal SIGINT, Interrupt. 0x00007f6ae34d2c54 in
> g_static_rw_lock_reader_lock () from /usr/lib/ libglib-2.0.so.0
> (gdb) bt
> #0  0x00007f6ae34d2c54 in g_static_rw_lock_reader_lock () from /usr/lib/
> libglib-2.0.so.0
> #1  0x00007f6ae3b5e256 in g_type_interface_peek () from /usr/lib/
> libgobject-2.0.so.0
> #2  0x00007f6ae4d3af99 in gtk_tree_model_iter_next () from /usr/lib/
> libgtk-x11-2.0.so.0

In all three traces so far, gtk_tree_model_iter_next has appeared near 
the top of the list.  The app seems to be spending an inordinate amount 
of time in that procedure and its children.  If you look further up the 
call stack (down the trace), you'll see that in all three, pan appeared 
to be inserting a header-row in that tree-view.  So it would appear to me 
that pan's doing OK (unless it's stuck in a loop that just happens to 
spend most of its time in the iter_next proc), but that the iter_next 
proc is taking a rather lot of cycles.

According to the trace, that proc is in libgtk_x11-2.0.so.0 .  Here, that 
underline is a dash, libgtk-x11-2.0.so.0, which is a symlink to the full 
versioned library, libgtk-x11-2.0.so.0.1200.11, in gtk+-2.12.11 as 
currently merged (installed by the package manager on Gentoo).

What version of gtk+ 2.x are you running?  Can you try finding a 
different version and downgrading/upgrading?  With some luck...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman