Well (as usual for a dedicated nerd) I've changed so many things at the same time that I can't tell which change may (if there is a bug) have caused this behavior:
I'm running the latest git [d7bd6aa1] as usual. I was fetching a gazillion headers from my primary news server when I decided to test pan's recent header-compression feature. I opened the 'edit servers' dialog and selected the 'XZVER' option (I already know this particular server supports XZVER) and clicked 'okay'. Well, pan's entire gui interface locked up instantly, including the 'edit servers' dialog box, and the network traffic halted at the same instant. However, I saw that the pan process was still consuming 100% of (one) CPU even while the pan gui remained completely unresponsive. Well, I thought, strace should give me some info, so I sicked strace on the pan process -- and strace gave me absolutely nothing even while the pan process was consuming 100% of (one) CPU. WTF? Next I sicked gdb on the pan process and found that pan was evidently stuck in some infinite loop involving the glib sockets and istream libs, but I lack the expertise to take this any further. As a postscript, I examined my ~/.pan2/servers.xml and found that pan had saved my 'XZVER' choice correctly before freezing up. I'm thinking (maybe?) that pan needs to open a new socket for the compressed- header istream instead of trying to read from the old (uncompressed) socket connection? This is all beyond my ken and I'm off to bed now... _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
