Your message dated Mon, 28 Apr 2008 11:17:09 +0000 with message-id <[EMAIL PROTECTED]> and subject line Bug#477931: fixed in rsync 3.0.2-2 has caused the Debian Bug report #477931, regarding rsync: Segfaults syncing the linux kernel archive. to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [EMAIL PROTECTED] immediately.) -- 477931: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477931 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems
--- Begin Message ---Package: rsync Version: 3.0.2-1 Severity: serious Tags: patch Hi, I can consitently make rsync segfault when trying to sync the linux kernel archive using version 3.0.2. It doesn't segfault using 2.6.9-2etch2. This has worked for weeks but started happening yesterday. This is what I got from gdb: Program received signal SIGSEGV, Segmentation fault. #0 0x0000000000434b84 in hashtable_find (tbl=0x0, key=-1, allocate_if_missing=0) at hashtable.c:59 59 int key64 = tbl->key64; (gdb) bt #0 0x0000000000434b84 in hashtable_find (tbl=0x0, key=-1, allocate_if_missing=0) at hashtable.c:59 #1 0x0000000000430278 in check_prior (file=0x2ae3c6632e78, gnum=-1, prev_ndx_p=0x7fffe8617564, flist_p=0x7fffe8617568) at hlink.c:269 #2 0x0000000000430433 in hard_link_check (file=0x2ae3c6632e78, ndx=799511, fname=0x7fffe861ba30 "scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-447fe96131da71732243925546a8d62bef99bea2.idx", statret=0, sxp=0x7fffe861b870, itemizing=1, code=FLOG) at hlink.c:298 #3 0x00000000004112d6 in recv_generator ( fname=0x7fffe861ba30 "scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-447fe96131da71732243925546a8d62bef99bea2.idx", file=0x2ae3c6632e78, ndx=799511, itemizing=1, code=FLOG, f_out=3) at generator.c:1504 #4 0x00000000004139c2 in generate_files (f_out=3, local_name=0x0) at generator.c:2214 #5 0x000000000041f651 in do_recv (f_in=3, f_out=3, local_name=0x0) at main.c:839 #6 0x000000000041fdbe in client_run (f_in=3, f_out=3, pid=-1, argc=1, argv=0x682338) at main.c:1077 #7 0x000000000043f035 in start_socket_client ( host=0x6827a8 "filehub.kernel.org", remote_argc=1, remote_argv=0x682330, argc=1, argv=0x682338) at clientserver.c:132 #8 0x00000000004204c0 in start_client (argc=1, argv=0x682338) at main.c:1243 #9 0x0000000000420cf5 in main (argc=2, argv=0x682330) at main.c:1511 (gdb) frame 1 #1 0x0000000000430278 in check_prior (file=0x2ae3c6632e78, gnum=-1, prev_ndx_p=0x7fffe8617564, flist_p=0x7fffe8617568) at hlink.c:269 269 if ((node = hashtable_find(prior_hlinks, gnum, 0)) != NULL) { (gdb) p prior_hlinks $1 = (struct hashtable *) 0x0 (gdb) p inc_recurse $2 = 0 prior_hlinks only seems to be used in case of !inc_recurse, so I have the feeling that I shouldn't be comming there in the first place. I'm guessing that the hashtable_find() should be inside an if (inc_recurse) as all other hashtable_find()'s are also doing that. I've attached a patch that does that. It seems to be working. PS: It's annoying that when a core file gets created that it's written in destination path instead of the directory where I started rsync. Kurt--- hlink.c.old 2008-04-25 19:39:15.000000000 +0000 +++ hlink.c 2008-04-25 19:39:49.000000000 +0000 @@ -266,15 +266,18 @@ F_HL_PREV(file) = prev_ndx = F_HL_PREV(fp); } - if ((node = hashtable_find(prior_hlinks, gnum, 0)) != NULL) { - assert(node->data != NULL); - if (CVAL(node->data, 0) != 0) { - *prev_ndx_p = -1; - *flist_p = NULL; - return node->data; + if (inc_recurse) + { + if ((node = hashtable_find(prior_hlinks, gnum, 0)) != NULL) { + assert(node->data != NULL); + if (CVAL(node->data, 0) != 0) { + *prev_ndx_p = -1; + *flist_p = NULL; + return node->data; + } + /* The prior file must have been skipped. */ + F_HL_PREV(file) = -1; } - /* The prior file must have been skipped. */ - F_HL_PREV(file) = -1; } *prev_ndx_p = -1;
--- End Message ---
--- Begin Message ---Source: rsync Source-Version: 3.0.2-2 We believe that the bug you reported is fixed in the latest version of rsync, which is due to be installed in the Debian FTP archive: rsync_3.0.2-2.diff.gz to pool/main/r/rsync/rsync_3.0.2-2.diff.gz rsync_3.0.2-2.dsc to pool/main/r/rsync/rsync_3.0.2-2.dsc rsync_3.0.2-2_amd64.deb to pool/main/r/rsync/rsync_3.0.2-2_amd64.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Paul Slootman <[EMAIL PROTECTED]> (supplier of updated rsync package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Format: 1.7 Date: Mon, 28 Apr 2008 13:06:35 +0200 Source: rsync Binary: rsync Architecture: source amd64 Version: 3.0.2-2 Distribution: unstable Urgency: low Maintainer: Paul Slootman <[EMAIL PROTECTED]> Changed-By: Paul Slootman <[EMAIL PROTECTED]> Description: rsync - fast remote file copy program (like rcp) Closes: 477931 Changes: rsync (3.0.2-2) unstable; urgency=low . * Fixed a crash if a non-incremental-recursion transfer has a skipped file in a set of hard-links. closes:#477931 Files: ff95e29de85c274cd3e20366c1956bcc 570 net optional rsync_3.0.2-2.dsc ccca08741a5921ec8b040f17089803f7 14808 net optional rsync_3.0.2-2.diff.gz 490c48e400ba605de1df2b7d0e73d06e 339978 net optional rsync_3.0.2-2_amd64.deb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIFbC9utvvqbTW3hMRAtsfAJ4wbNSA78DKWETz4XLsDfq6Dhww/ACfVEQJ SGhE7kVoGsaZgVEidmvxd90= =Fl4q -----END PGP SIGNATURE-----
--- End Message ---
