>> I'm trying to track that down, but still making my way around the new >> code. It looks like Pan's corrupting its article counters somewhere. >> Before I start Pan, I see: >> >> $ cd ~/.pan2 >> $ grep easynet.test * >> newsgroups.dsc:easynet.test:Test group for customers of Easynet PLC UK. >> newsgroups.xov:easynet.test 44 23 1:1641 >> newsrc-1:easynet.test: 0-1641 >> >> Now, I start Pan, go to that group (easynet.test) and exit Pan. After >> that, I see: >> >> $ grep easynet.test * >> newsgroups.dsc:easynet.test:Test group for customers of Easynet PLC UK. >> newsgroups.xov:easynet.test 22 0 1:1641 >> newsrc-1:easynet.test: 0-4294967295 >> >> Now the newsrc string is 0-4294967295. Now, that big number looks >> suspiciously like (unsigned int) -1, doesn't it. :-)
> Hm. I don't have the code handy right now but this smells like > tasks/task-xover.c's _high map. Real simple to test, just put > print statements after all the _data.get_xover_high() and > before each _data.set_xover_high(). More ideas on this. 4294967295 is ULONG_MAX. task-xover.cc sets _high to max (_high, number) on each xover line where number is gotten with strtoul() from the xover line. strtoul() handles an overflow condition by returning ULONG_MAX and setting errno to ERANGE. Currently the TaskXOver::on_nntp_line() doesn't have any errno checking... You might somehow be getting a corrupted xover line from easynet, or maybe Pan's feeding you the end-of-lines control string (a line consisting of just a dot), or some other problem I haven't thought of. I'm not seeing this newsrc problem on my end, so Chris, could you put some choice assertions/print statements in TaskXOver::on_nntp_line() to test this theory? _______________________________________________ Pan-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/pan-devel
