(not quite) reproducible segfaults in 3.0.3

In debian bug #498083 ([url]http://bugs.debian.org/498083[/url]) someone is getting
segfaults reasonably consistently, however when using -vvvv it doesn't
happen...

Fortunately Sven was able to get a good backtrace. I can't quite see
what's causing the problem; it does seem to be related to xattrs.

Please see the bugs report at the url above for the details.
Any help much appreciated.


Paul
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: [url]https://lists.samba.org/mailman/listinfo/rsync[/url]
Before posting, read: [url]http://www.catb.org/~esr/faqs/smart-questions.html[/url]

I think I isolated that exact same crash just last night. Here's my
symbolized crash report:

Process: rsync [17295]
Path: /usr/local/bin/rsync
Identifier: rsync
Version: ??? (???)
Code Type: PPC (Native)
Parent Process: rsync [17294]

Date/Time: 2008-09-17 05:09:04.001 -0500
OS Version: Mac OS X Server 10.5.4 (9E17)
Report Version: 6

Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000005
Crashed Thread: 0

Thread 0 Crashed:
0 rsync 0x0001b488 xattr_diff (in rsync)
(xattrs.c:456)
1 rsync 0x00025c5c itemize (in rsync)
(generator.c:743)
2 rsync 0x00003bc4 maybe_hard_link (in
rsync) (hlink.c:240)
3 rsync 0x00004448 finish_hard_link (in
rsync) (hlink.c:504)
4 rsync 0x0002931c check_for_finished_files
(in rsync) (generator.c:2198)
5 rsync 0x00029cd4 generate_files (in
rsync) (generator.c:2370)
6 rsync 0x0004201c do_recv (in rsync)
(main.c:841)
7 rsync 0x00042a58 main (in rsync) (main.c:
1395)
8 rsync 0x00043b70 write_stream_flags (in
rsync) (batch.c:99)
9 rsync 0x00035240 local_child (in rsync)
(pipe.c:159)
10 rsync 0x00043a68 main (in rsync) (main.c:
475)
11 rsync 0x00001cc8 _start + 756
12 rsync 0x000019cc start + 44

Thread 0 crashed with PPC Thread State 32:
srr0: 0x0001b488 srr1: 0x0000d030 dar: 0x00000005 dsisr: 0x40000000
r0: 0x00025c60 r1: 0xbfffcd20 r2: 0x00060000 r3: 0x02fad110
r4: 0x00000001 r5: 0x00000001 r6: 0x00006929 r7: 0x00000001
r8: 0x00000010 r9: 0x00000000 r10: 0x00000000 r11: 0x03c40000
r12: 0x95ec373c r13: 0x0004a79c r14: 0x0004a89c r15: 0x00076f66
r16: 0x00000006 r17: 0x00000001 r18: 0x0005860c r19: 0x00058660
r20: 0xbfffce98 r21: 0x00060000 r22: 0xbfffd7f8 r23: 0x00000000
r24: 0xbfffd7f8 r25: 0xbfffcf68 r26: 0x00000001 r27: 0x00076f78
r28: 0x0005b34c r29: 0xbfffcef8 r30: 0x02fad110 r31: 0x0000500c
cr: 0x84004224 xer: 0x20000000 lr: 0x00025c60 ctr: 0x00000000
vrsave: 0x00000000

Binary Images:
0x1000 - 0x57ffb +rsync ??? (???)
<f42940865c5c94c600a975248d4322da> /usr/local/bin/rsync
0x8fe00000 - 0x8fe30b23 dyld 96.2 (???)
<ef2061020a88c4fe1f40b8d9cb1a6101> /usr/lib/dyld
0x9097e000 - 0x90a74ffc libiconv.2.dylib ??? (???)
<05ae1fcc97404173b2f9caef8f8be797> /usr/lib/libiconv.2.dylib
0x94132000 - 0x9413dffb libgcc_s.1.dylib ??? (???)
<ea47fd375407f162c76d14d64ba246cd> /usr/lib/libgcc_s.1.dylib
0x95eb7000 - 0x96050fe3 libSystem.B.dylib ??? (???)
<79cf3ef34f92361dc6263d884c723c24> /usr/lib/libSystem.B.dylib
0x9680c000 - 0x96811ff6 libmathCommon.A.dylib ??? (???) /usr/lib/
system/libmathCommon.A.dylib
0xffff8000 - 0xffff9703 libSystem.B.dylib ??? (???) /usr/lib/
libSystem.B.dylib



xattrs.c:456 for me is:

int xattr_diff(struct file_struct *file, stat_x *sxp, int find_all)
{
item_list *lst = rsync_xal_l.items;
rsync_xa *snd_rxa, *rec_rxa;
int snd_cnt, rec_cnt;
int cmp, same, xattrs_equal = 1;

if (sxp && XATTR_READY(*sxp)) {
rec_rxa = sxp->xattr->items;
rec_cnt = sxp->xattr->count;
} else {
rec_rxa = NULL;
rec_cnt = 0;
}

--> if (F_XATTR(file) >= 0) <--
lst += F_XATTR(file);
else
lst = &empty_xattr;




I've seen the same crash a few times, but I haven't been able to
reliably reproduce it.

Mike


On Sep 23, 2008, at 6:04 AM, Paul Slootman wrote:
[color=blue]
> In debian bug #498083 ([url]http://bugs.debian.org/498083[/url]) someone is
> getting
> segfaults reasonably consistently, however when using -vvvv it doesn't
> happen...
>
> Fortunately Sven was able to get a good backtrace. I can't quite see
> what's causing the problem; it does seem to be related to xattrs.
>
> Please see the bugs report at the url above for the details.
> Any help much appreciated.
>
>
> Paul
> --
> Please use reply-all for most replies to avoid omitting the mailing
> list.
> To unsubscribe or change options: [url]https://lists.samba.org/mailman/listinfo/rsync[/url]
> Before posting, read: [url]http://www.catb.org/~esr/faqs/smart-questions.html[/url][/color]

--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: [url]https://lists.samba.org/mailman/listinfo/rsync[/url]
Before posting, read: [url]http://www.catb.org/~esr/faqs/smart-questions.html[/url]

On Tue, Sep 23, 2008 at 01:04:50PM +0200, Paul Slootman wrote:[color=blue]
> In debian bug #498083 ([url]http://bugs.debian.org/498083[/url]) someone is getting
> segfaults reasonably consistently, however when using -vvvv it doesn't
> happen...[/color]

Much appreciated! That info made me immediately think that there was an
xattr point not being initialized, and indeed, that was the cause. The
attached patch should hopefully fix this. It should also fix up the
output of itemized xattr differences when one of the --*-dest options is
enabled, a new hard-link is created, and this new file doesn't match the
alt-dest file.

Anyone seeing this crash, please give this a try. Thanks!

...wayne..

--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: [url]https://lists.samba.org/mailman/listinfo/rsync[/url]
Before posting, read: [url]http://www.catb.org/~esr/faqs/smart-questions.html[/url]