[Pan-devel] newsrc corruption theory (Was: Pan 0.91 issues)

[Charles Kerr]

>> 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?