[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[leafnode-list] Re: 2.0.0.alpha20081120a (and earlier) texpir?e -r?segmentation fault
On Wed, 10 Dec 2008 08:21:11 -0600 Bulgrien, Kevin wrote:
>> The culprit is a header on the groupinfo file. The old texpire has
>> no problem with it. The new one has a big problem with it. I did
>> not put that header in there to my recollection. I took it out,
>> and texpire -r completes with no error. I'd say that a segfault is
>> unwarranted for junk in a configuration file. The old texpire is not
>> phased by it.
"leaf.node/groupinfo" is not a configuration file. Leafnode keeps a
list of newsgroups here which are known to it. It contains upstream
info and housekeeping stuff. It is not for "human consumption", and it
is obviously unsafe to mess with it.
I couldn't tell exactly from the strace you sent, but there's an
indication that it had to do with dynamic memory allocation.
So this is what happens when people put an errornous entry into this
file, leafnode thinks all numbers are correct, does its magic and falls
flat on the users nose 8-).
>> Old version:
>> $ head -2 /home/news/leaf.node/groupinfo | od -ax
>> 0000000 # A sp 4 6 nl k r a y t e c
>> h . a
>> New version:
>> $ head -2 groupinfo | od -ax
>> 0000000 # A sp 6 2 nl k r a y t e c
>> h . a
> That header seems to be, amongst other things, a count of
> groups... Confession time is probably now. I did something
> a bit dodgy during this spool copy - merged two local group
> spools. I changed the number of groups in group info without
> updating the header. Perhaps that is the secret sauce to the
> seg fault? It may not gracefully handle an inaccurate header.
Fist off: thanks for following up on this issue. I wondered why
I couldn't reproduce the problem, now we know. I am not sure how much
effort leafnode should put into anticipating users changing vital
information files that are supposed to be handled by leafnode only.
My opinion is: you got what you deserved. OTOH, you get extra points
for not keeping us wondering if unknown monsters lurk in the leafnode
BTW, I once tried something similiar: There was one local newsgroup
that had to be split into a number of new ones, but I never thought of
messing with groupinfo, I tried to frob the ".overview" files within
the groups directory itself. Didn't work. Fortunately, after simply
adding the new groups to etc/leafnode/local.groups they started to work
immediately, and I didn't need the old group.
Maybe we should start a wiki with "tips & tricks" or "what you shouldn't
expect leafnode to do, but may get away with yet" 8-)
leafnode-list mailing list