I seem to get segfaults quite regularly with 1.10.7. When I have time I
try to track down the bug. Other times I will work around the bug.
I just tried to do a checkin on a directory in which I had previously
scheduled several files with the `add' command. When it got to a
certain file it segfaulted in find_checkedout_proc(); the stack looks
like this:
commit -> start_recursion -> do_recursion -> walklist ->
do_dir_proc -> do_recursion -> walklist -> do_file_proc ->
commit_file_proc -> finaladd -> Checkin -> RCS_checkout ->
walklist -> find_checkedout_proc
here's the code leading up to it:
link = lookup_file_by_inode (path);
free (path);
free (dir);
if (link == NULL)
{
/* We haven't seen this file -- maybe it hasn't been checked
out yet at all. */
return 0;
}
hlinfo = (struct hardlink_info *) link->data;
if (hlinfo->checked_out)
{
/* This file has been checked out recently, so it's safe to
link to it. */
*uptodate = link;
}
the segfault is in the dereference of hlinfo->checked_out; the problem
is that link->data is null. Where link is assigned from the return of
lookup_file_by_inode(), it apparently returns like this:
p = findnode ((List *) hp->data, filepath);
if (p == NULL)
{
p = getnode();
p->type = UNKNOWN;
p->key = xstrdup (filepath);
p->data = NULL;
(void) addnode ((List *) hp->data, p);
}
return p;
(p == NULL). I believe the code in find_checkedout_proc() actually
meant to return zero if (link->data == NULL), instead of if (link ==
NULL). I can't think of a situation where (link == NULL) because in
lookup_file_by_inode() as shown above there is an explicit check to be
sure that it isn't null (if it is, a new Node is allocated in getnode())
before returning to find_checkedout_proc().
Can someone confirm that CVS developers read this list? I've only just a
few days ago joined and started using CVS, so I don't know how active
development is. I can't use it in production until I get rid of some of
these segfaults that keep occuring. Platform is Linux/IA32/glibc-2.1
BTW.
If developers do read the list, can one of them confirm that this is a
bug so I can incorporate it locally and rest knowing behavior is still
correct?
If developers do not read the list, does anyone know of a list that
developers monitor or must I contact cyclic somehow?
Thanks for any help.
--
Scott
