Bug#498083: rsync: segfaults reproducible
Please try out the patch I posted to the rsync mailing list. Here's a couple different ways to look at it (the first has an easy link for downloading the patch, the second is easier for viewing the patch): http://lists.samba.org/archive/rsync/2008-September/021778.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg22528.html ..wayne.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498083: rsync: segfaults reproducible
Paul Slootman wrote: On Wed 10 Sep 2008, Sven Hartge wrote: (gdb) p *(sxp-xattr) Cannot access memory at address 0x4 Hmm. Interesting. Very strange indeed... Before I forward the bug upstream, could I ask you to run the transfer with -vvv added, which will generate copious debugging output? That may help with pinpointing the problem. Funny thing is: I have since not been able to reproduce this segfault. Before I tried to generate a log with -vvv it died reliably, but now: not a chance. I will try to get the log though. Grüße, Sven. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498083: rsync: segfaults reproducible
On Fri 12 Sep 2008, Sven Hartge wrote: note that I have uploaded version 3.0.4-2, that version may also have updates that fix the problem. I noticed and I am already testing this. Do you know if there have been any code changes around the place the segfault occured? Not as far as I can see. Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498083: rsync: segfaults reproducible
Paul Slootman wrote: On Fri 12 Sep 2008, Sven Hartge wrote: Funny thing is: I have since not been able to reproduce this segfault. Before I tried to generate a log with -vvv it died reliably, but now: not a chance. I will try to get the log though. OK; note that I have uploaded version 3.0.4-2, that version may also have updates that fix the problem. I noticed and I am already testing this. Do you know if there have been any code changes around the place the segfault occured? Grüße, Sven. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498083: rsync: segfaults reproducible
On Fri 12 Sep 2008, Sven Hartge wrote: Funny thing is: I have since not been able to reproduce this segfault. Before I tried to generate a log with -vvv it died reliably, but now: not a chance. I will try to get the log though. OK; note that I have uploaded version 3.0.4-2, that version may also have updates that fix the problem. Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498083: rsync: segfaults reproducible
Thanks for the rather complete report... On Sat 06 Sep 2008, Sven Hartge wrote: I am sorry for this quite generic subject, but this is it: rsync segfaults while rsyncing. Situation: hild(laptop)skuld (workstation, segfaulting receiver) / (/dev/hda1) -- /mnt/backup (/mnt/mybook/backup/hild-backup.img ext3 via loop) [...] It dies inside while rsyncing my cowbuilder chroot(), to my totally uneducated eye (and brain) this looks like a problem with -X, because rsync is able to complete the job while not using -X. Kernel is configured with XATTR support: CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y but the mount of the target filesystem does not use it: /mnt/mybook/backup/hild-backup.img on /mnt/backup type ext3 (rw,loop=/dev/loop0) How about the source directory, / ? (gdb) bt #0 0x08080403 in xattr_diff (file=0xb534a220, sxp=0xbfbab7fc, find_all=1) at xattrs.c:445 [...] (gdb) bt full #0 0x08080403 in xattr_diff (file=0xb534a220, sxp=0xbfbab7fc, find_all=1) at xattrs.c:445 lst = (item_list *) 0x80cdc80 snd_rxa = (rsync_xa *) 0x807e240 rec_rxa = (rsync_xa *) 0xbfbaa79c snd_cnt = 1 rec_cnt = 0 cmp = 1 same = 135028592 xattrs_equal = 1 Could you also do a p *sxp and p *(sxp-xattr) (if it's not null) ? I'm wondering wondering whether something there might be null unexpectedly... thanks, Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498083: rsync: segfaults reproducible
Paul Slootman wrote:
On Sat 06 Sep 2008, Sven Hartge wrote:
It dies inside while rsyncing my cowbuilder chroot(), to my totally
uneducated
eye (and brain) this looks like a problem with -X, because rsync is able to
complete the job while not using -X.
Kernel is configured with XATTR support:
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
but the mount of the target filesystem does not use it:
/mnt/mybook/backup/hild-backup.img on /mnt/backup type ext3
(rw,loop=/dev/loop0)
How about the source directory, / ?
No ACLs or other funky stuff there:
/dev/hda1 on / type ext3 (rw,relatime,errors=remount-ro,barrier=1)
(gdb) bt
#0 0x08080403 in xattr_diff (file=0xb534a220, sxp=0xbfbab7fc, find_all=1)
at xattrs.c:445
[...]
(gdb) bt full
#0 0x08080403 in xattr_diff (file=0xb534a220, sxp=0xbfbab7fc, find_all=1)
at xattrs.c:445
lst = (item_list *) 0x80cdc80
snd_rxa = (rsync_xa *) 0x807e240
rec_rxa = (rsync_xa *) 0xbfbaa79c
snd_cnt = 1
rec_cnt = 0
cmp = 1
same = 135028592
xattrs_equal = 1
Could you also do a p *sxp and p *(sxp-xattr) (if it's not null) ?
I'm wondering wondering whether something there might be null
unexpectedly...
(gdb) p *sxp
$1 = {st = {st_dev = 1792, __pad1 = 0, __st_ino = 1119785, st_mode = 33261,
st_nlink = 2,
st_uid = 0, st_gid = 0, st_rdev = 0, __pad2 = 0, st_size = 14112,
st_blksize = 4096,
st_blocks = 32, st_atim = {tv_sec = 1221055064, tv_nsec = 0}, st_mtim =
{tv_sec = 1218054609,
tv_nsec = 0}, st_ctim = {tv_sec = 1221055064, tv_nsec = 0}, st_ino =
1119785},
acc_acl = 0x8324ee8, def_acl = 0x0, xattr = 0x4}
(gdb) p *(sxp-xattr)
Cannot access memory at address 0x4
Hmm. Interesting.
Grüße,
Sven.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498083: rsync: segfaults reproducible
On Wed 10 Sep 2008, Sven Hartge wrote: (gdb) p *(sxp-xattr) Cannot access memory at address 0x4 Hmm. Interesting. Very strange indeed... Before I forward the bug upstream, could I ask you to run the transfer with -vvv added, which will generate copious debugging output? That may help with pinpointing the problem. And just to be sure: both ends of the transfer are running 3.0.3-2 ? thanks, Paul Slootman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498083: rsync: segfaults reproducible
Paul Slootman wrote: On Wed 10 Sep 2008, Sven Hartge wrote: (gdb) p *(sxp-xattr) Cannot access memory at address 0x4 Hmm. Interesting. Very strange indeed... Before I forward the bug upstream, could I ask you to run the transfer with -vvv added, which will generate copious debugging output? That may help with pinpointing the problem. Will take some time. I will need to trim the log, as right of now I am up to over 200MB in size and it still has not finished rsyncing. And just to be sure: both ends of the transfer are running 3.0.3-2 ? Yes. Debian Sid on both ends, updated at least once a day. Grüße, Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498083: rsync: segfaults reproducible
Package: rsync
Version: 3.0.3-2
Severity: normal
I am sorry for this quite generic subject, but this is it: rsync segfaults
while rsyncing.
Situation:
hild(laptop)skuld (workstation, segfaulting receiver)
/ (/dev/hda1) -- /mnt/backup
(/mnt/mybook/backup/hild-backup.img ext3 via loop)
hild is running the rsync-daemon (as root) and skuld uses '/usr/bin/rsync
-aHAXxv --progress --delete-before --stats --numeric-ids hild::root/
/mnt/backup/hild' to backup the while /-filesystem from hild to an ext3 on a
loop-file.
After some rsyncing, one part of the receiving rsync segfaults, the other part
stays alive (see further down).
I recompiled it with debug,nostrip to gather the following backtrace.
It dies inside while rsyncing my cowbuilder chroot(), to my totally uneducated
eye (and brain) this looks like a problem with -X, because rsync is able to
complete the job while not using -X.
Kernel is configured with XATTR support:
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
but the mount of the target filesystem does not use it:
/mnt/mybook/backup/hild-backup.img on /mnt/backup type ext3 (rw,loop=/dev/loop0)
---
(gdb) bt
#0 0x08080403 in xattr_diff (file=0xb534a220, sxp=0xbfbab7fc, find_all=1) at
xattrs.c:445
#1 0x0805556c in itemize (
fnamecmp=0xbfbaa79c
var/cache/pbuilder/base.cow/usr/share/man/man8/fsck.ext2.8.gz,
file=0xb534a220, ndx=616834, statret=0, sxp=0xbfbab7fc, iflags=20488,
fnamecmp_type=0 '\0',
xname=0xbfbab8cc
var/cache/pbuilder/base.cow/usr/share/man/man8/e2fsck.8.gz)
at generator.c:676
#2 0x080766fb in maybe_hard_link (file=0xb534a220, ndx=616834,
fname=0xbfbaa79c
var/cache/pbuilder/base.cow/usr/share/man/man8/fsck.ext2.8.gz, statret=0,
sxp=0xbfbab7fc,
oldname=0xbfbab8cc
var/cache/pbuilder/base.cow/usr/share/man/man8/e2fsck.8.gz,
old_stp=0xbfbab79c,
realname=0xbfbab8cc
var/cache/pbuilder/base.cow/usr/share/man/man8/e2fsck.8.gz,
itemizing=1, code=FLOG) at hlink.c:235
#3 0x080774c8 in finish_hard_link (file=0xb534a220,
fname=0xbfbab8cc
var/cache/pbuilder/base.cow/usr/share/man/man8/e2fsck.8.gz,
fin_ndx=616824, stp=0xbfbab79c, itemizing=1, code=FLOG, alt_dest=-1) at
hlink.c:495
#4 0x08059d31 in check_for_finished_files (itemizing=1, code=FLOG,
check_redo=0)
at generator.c:2085
#5 0x0805a676 in generate_files (f_out=5, local_name=0x0) at generator.c:2262
#6 0x080663fc in do_recv (f_in=5, f_out=5, local_name=0x0) at main.c:848
#7 0x08066c33 in client_run (f_in=5, f_out=5, pid=-1, argc=1, argv=0x80b9a04)
at main.c:1086
#8 0x08085034 in start_socket_client (host=0x80b9bb0 hild, remote_argc=1,
remote_argv=0x80b9a00, argc=1, argv=0x80b9a04) at clientserver.c:130
#9 0x080672eb in start_client (argc=1, argv=0x80b9a04) at main.c:1252
#10 0x08067bed in main (argc=2, argv=0x80b9a00) at main.c:1520
(gdb) bt full
#0 0x08080403 in xattr_diff (file=0xb534a220, sxp=0xbfbab7fc, find_all=1) at
xattrs.c:445
lst = (item_list *) 0x80cdc80
snd_rxa = (rsync_xa *) 0x807e240
rec_rxa = (rsync_xa *) 0xbfbaa79c
snd_cnt = 1
rec_cnt = 0
cmp = 1
same = 135028592
xattrs_equal = 1
#1 0x0805556c in itemize (
fnamecmp=0xbfbaa79c
var/cache/pbuilder/base.cow/usr/share/man/man8/fsck.ext2.8.gz,
file=0xb534a220, ndx=616834, statret=0, sxp=0xbfbab7fc, iflags=20488,
fnamecmp_type=0 '\0',
xname=0xbfbab8cc
var/cache/pbuilder/base.cow/usr/share/man/man8/e2fsck.8.gz)
at generator.c:676
keep_time = 1
#2 0x080766fb in maybe_hard_link (file=0xb534a220, ndx=616834,
fname=0xbfbaa79c
var/cache/pbuilder/base.cow/usr/share/man/man8/fsck.ext2.8.gz, statret=0,
sxp=0xbfbab7fc,
oldname=0xbfbab8cc
var/cache/pbuilder/base.cow/usr/share/man/man8/e2fsck.8.gz,
old_stp=0xbfbab79c,
realname=0xbfbab8cc
var/cache/pbuilder/base.cow/usr/share/man/man8/e2fsck.8.gz,
itemizing=1, code=FLOG) at hlink.c:235
No locals.
#3 0x080774c8 in finish_hard_link (file=0xb534a220,
fname=0xbfbab8cc
var/cache/pbuilder/base.cow/usr/share/man/man8/e2fsck.8.gz,
fin_ndx=616824, stp=0xbfbab79c, itemizing=1, code=FLOG, alt_dest=-1) at
hlink.c:495
val = 16877
prev_sx = {st = {st_dev = 1792, __pad1 = 0, __st_ino = 3468167, st_mode
= 33188,
st_nlink = 4, st_uid = 0, st_gid = 0, st_rdev = 0, __pad2 = 0, st_size =
4399,
st_blksize = 4096, st_blocks = 16, st_atim = {tv_sec = 1220735316, tv_nsec
= 0}, st_mtim = {
tv_sec = 1220364535, tv_nsec = 0}, st_ctim = {tv_sec = 1220735316,
tv_nsec = 0},
st_ino = 3468167}, acc_acl = 0x85f0888, def_acl = 0x0, xattr = 0xb}
st = {st_dev = 1792, __pad1 = 0, __st_ino = 3468166, st_mode = 33188,
st_nlink = 1,
st_uid = 0, st_gid = 0, st_rdev = 0, __pad2 = 0, st_size = 4399, st_blksize =
4096,
st_blocks = 16, st_atim
