On Wed, 06 Aug 2008 17:06:30 +0000, Duncan wrote: > Rhialto <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], 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. _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
