Quoting Larry Jones <[EMAIL PROTECTED]>:

> A traceback from the debugger will be much more useful than straces.

Here is the backtrace from the child process on the server side (when
connecting via ssh or kerberized rsh with an :ext: CVSROOT). If only one 
file is committed or has changed, everything works great. cvs server only 
dies when multiple files are committed.

The problem shows up on line 320 of hash.c from cvs 1.10.8. I am sure
that the root cause occurs somewhere else, but I am not familiar enough
with the code to spot it immediately. Hopefully, it is obvious to someone.
If someone has any pointers of  how to proceed, please let me know.

Thanks!
benjy

#0  strcmp (p1=0x0, p2=0x8188e88 "/tmp/cvs-serv5301/foo.test")
    at ../sysdeps/generic/strcmp.c:38
  38      in ../sysdeps/generic/strcmp.c

#1  0x80619e1 in findnode (list=0x8188b00,
    key=0x8188e88 "/tmp/cvs-serv5301/foo.test") at hash.c:320
  320             if (strcmp (p->key, key) == 0)

  (gdb) print *p
  $40 = {type = HEADER, next = 0x0, prev = 0x0, hashnext = 0x8188e00,
    hashprev = 0x8188e00, key = 0x0, data = 0x0, delproc = 0}

  (gdb) print *head
  $42 = {type = UPDATE, next = 0x8184718, prev = 0x81848c8,
    hashnext = 0x8188db8, hashprev = 0x8188db8, key = 0x8184b58 "foo.test",
    data = 0x8188e28 "\004", delproc = 0x805a764 <update_delproc>}

#2  0x806117b in lookup_file_by_inode (
    filepath=0x8188e88 "/tmp/cvs-serv5301/foo.test") at hardlink.c:99
  99          p = findnode ((List *) hp->data, filepath);

#3  0x8058838 in check_fileproc (callerdat=0x0, finfo=0xbffffa38)
    at commit.c:1048
  1048                    linkp = lookup_file_by_inode (fullpath);

#4  0x807f334 in do_file_proc (p=0x8180328, closure=0xbffffa2c)
    at recurse.c:821
  821         ret = frfile->frame->fileproc (frfile->frame->callerdat, finfo);

#5  0x8061aaa in walklist (list=0x8180098, proc=0x807f1f0 <do_file_proc>,
    closure=0xbffffa2c) at hash.c:370
  370             err += proc (p, closure);

#6  0x807f10e in do_recursion (frame=0xbffffae0) at recurse.c:725
  725             err += walklist (filelist, do_file_proc, &frfile);

#7  0x807fbea in unroll_files_proc (p=0x8124c48, closure=0xbffffae0)
    at recurse.c:1194
  1194        err += do_recursion (frame);

#8  0x8061aaa in walklist (list=0x817fe30, proc=0x807fa60 <unroll_files_proc>,
    closure=0xbffffae0) at hash.c:370
  370             err += proc (p, closure);

#9  0x807eccc in start_recursion (fileproc=0x80580a4 <check_fileproc>,
    filesdoneproc=0x8058a74 <check_filesdoneproc>,
    direntproc=0x80588c8 <check_direntproc>, dirleaveproc=0, callerdat=0x0,
    argc=2, argv=0x8124ab8, local=0, which=1, aflag=0, readlock=0,
    update_preload=0x0, dosrcs=1) at recurse.c:343
  343       err += walklist (files_by_dir, unroll_files_proc, (void *) &frame);

#10 0x8057d3f in commit (argc=2, argv=0x8124fdc) at commit.c:650
  650         err = start_recursion (check_fileproc, check_filesdoneproc,

#11 0x80863b8 in do_cvs_command (cmd_name=0x810cb6d "commit",
    command=0x80574b8 <commit>) at server.c:2753
  2753            exitstatus = (*command) (argument_count, argument_vector);

#12 0x8087242 in serve_ci (arg=0x8124742 "") at server.c:3391
  3391        do_cvs_command ("commit", commit);

#13 0x80890ab in server (argc=1, argv=0xbffffe18) at server.c:5042
  5042                        (*rq->func) (cmd);

#14 0x806d55b in main (argc=1, argv=0xbffffe18) at main.c:1008
  1008                err = (*(cm->func)) (argc, argv);


===============================================================

If I commit multiple files or you commit the directory when multiple
files have been changed, I get a segfault.

[Note: this was from a different run than the above backtrace.]

Breakpoint 1, findnode (list=0x8189540,
    key=0x81898c8 "/tmp/cvs-serv5437/foo.test") at hash.c:320
320             if (strcmp (p->key, key) == 0)
(gdb) step
strcmp (p1=0x0, p2=0x81898c8 "/tmp/cvs-serv5437/foo.test")
    at ../sysdeps/generic/strcmp.c:32
32      ../sysdeps/generic/strcmp.c: No such file or directory.
(gdb) step
33      in ../sysdeps/generic/strcmp.c
(gdb) step
38      in ../sysdeps/generic/strcmp.c
(gdb) step

Program received signal SIGSEGV, Segmentation fault.
strcmp (p1=0x0, p2=0x81898c8 "/tmp/cvs-serv5437/foo.test")
    at ../sysdeps/generic/strcmp.c:38
38      in ../sysdeps/generic/strcmp.c

(gdb) info f
Stack level 0, frame at 0xbffff8ec:
 eip = 0x400a0bb0 in strcmp (../sysdeps/generic/strcmp.c:38);
    saved eip 0x80619e1
 called by frame at 0xbffff908
 source language c.
 Arglist at 0xbffff8ec, args: p1=0x0, p2=0x81898c8 "/tmp/cvs-serv5437/foo.test"
 Locals at 0xbffff8ec, Previous frame's sp is 0x0
 Saved registers:
  ebp at 0xbffff8ec, esi at 0xbffff8e8, eip at 0xbffff8f0

=================================================================

For comparison, here is what it looks like when the commit succeeds.

This case works fine:              cvs -z3 commit -m "benjy: testing" foo.test

If only one file has been
modified, this works fine also:    cvs -z3 commit -m "benjy: testing"

Breakpoint 1, findnode (list=0x8182c60, key=0x8188448 "foo.test") at hash.c:320
320             if (strcmp (p->key, key) == 0)
(gdb) step
strcmp (p1=0x8188308 "foo.test", p2=0x8188448 "foo.test")
    at ../sysdeps/generic/strcmp.c:32
32      ../sysdeps/generic/strcmp.c: No such file or directory.
(gdb) step
33      in ../sysdeps/generic/strcmp.c

(gdb) step
38      in ../sysdeps/generic/strcmp.c
(gdb) step
39      in ../sysdeps/generic/strcmp.c
(gdb) step
40      in ../sysdeps/generic/strcmp.c
(gdb) step
43      in ../sysdeps/generic/strcmp.c
(gdb) step
38      in ../sysdeps/generic/strcmp.c

<snip>

Breakpoint 1, findnode (list=0x8188780,
    key=0x818d7a0 "/tmp/cvs-serv5469/foo.test") at hash.c:320
320             if (strcmp (p->key, key) == 0)
(gdb) step
strcmp (p1=0x8188bc0 "/tmp/cvs-serv5469/foo.test",
    p2=0x818d7a0 "/tmp/cvs-serv5469/foo.test")
    at ../sysdeps/generic/strcmp.c:32
32      ../sysdeps/generic/strcmp.c: No such file or directory.



1975 Cahaba Valley Road                                         (205) 988-4268
Indian Springs, AL 35124                                    [EMAIL PROTECTED]

Reply via email to