https://bugzilla.samba.org/show_bug.cgi?id=8666
--- Comment #1 from Chris Dunlop <ch...@onthe.net.au> 2011-12-16 13:40:01 UTC --- (In reply to comment #0) > There are at least 2 recursive calls when running --debug=all9: > > (gdb) bt > #1 0x0000000000434996 in perform_io (needed=60, flags=4) at ../rsync/io.c:608 > #2 0x0000000000435b71 in send_msg (code=MSG_INFO, buf=0x7fffa60c7da0 > "[receiver] perform_io(60, msgroom) needs to flush 33\n", len=53, convert=0) > at > ../rsync/io.c:955 > #3 0x0000000000429840 in rwrite (code=FINFO, buf=0x7fffa60c7da0 "[receiver] > perform_io(60, msgroom) needs to flush 33\n", len=53, is_utf8=0) at > ../rsync/log.c:277 > #4 0x0000000000429f37 in rprintf (code=FINFO, format=0x46c8c8 "[%s] > perform_io(%ld, msgroom) needs to flush %ld\n") at ../rsync/log.c:433 > #5 0x0000000000434996 in perform_io (needed=60, flags=4) at ../rsync/io.c:608 > > ...and so on ad-infinitum. If the rprintf() at io.c:608 is patched out, you > get > this instead: > > (gdb) bt > #0 0x0000000000429a11 in rwrite (code=FINFO, buf=0x7fff3006b8e0 "[generator] > reduced size of iobuf.msg (-3)\n", len=43, is_utf8=0) at ../rsync/log.c:321 > #1 0x0000000000429f37 in rprintf (code=FINFO, format=0x46c6e8 "[%s] reduced > size of %s (-%d)\n") at ../rsync/log.c:433 > #2 0x00000000004345a5 in reduce_iobuf_size (out=0x6839c0, new_size=32765) at > ../rsync/io.c:488 > #3 0x0000000000435b46 in send_msg (code=MSG_INFO, buf=0x7fff3006d770 > "[generator] reduced size of iobuf.msg (-3)\n", len=43, convert=0) at > ../rsync/io.c:964 > #4 0x0000000000429a16 in rwrite (code=FINFO, buf=0x7fff3006d770 "[generator] > reduced size of iobuf.msg (-3)\n", len=43, is_utf8=0) at ../rsync/log.c:321 > > ...and so on ad-infinitum. If the rprintf() at io.c:488 is patched out you no > longer get these recursive debug calls (but might there be others lurking?). > > For what it's worth, this was whilst running: > > /tmp/rsync-testing --rsync-path=/tmp/rsync-testing -aHXX --numeric-ids > --debug=all9 --link-dest=../A --link-dest=../B C/ server:$PWD/C/ > > ...where the directory hierarchies are quite substantial. After those calls are patched out but still with --debug=all9, I get a 29K line debug output that ends in: unexpected tag 95 [sender/inc] [sender] _exit_cleanup(code=12, file=../rsync/io.c, line=1615): entered rsync error: error in rsync protocol data stream (code 12) at ../rsync/io.c(1615) [sender=3.1.0dev] [sender] _exit_cleanup(code=12, file=../rsync/io.c, line=1615): about to call exit(12) ...and the receiving side got only as far as creating the top level directory. Same thing down to --debug=all4. Even down at --debug=all1 I get an aborted transfer: [sender] send_msg(0, 65532) rsync: [sender] write error: Broken pipe (32) [sender] got msg=2, len=31 [generator] send_msg(0, 22907) rsync error: error in rsync protocol data stream (code 12) at ../rsync/io.c(823) [sender=3.1.0dev] [sender] _exit_cleanup(code=10, file=../rsync/io.c, line=823): about to call exit(12) Looks like something in --debug=all is writing into the io stream? Without --debug=all the transfer progresses fine. But that doesn't help me debug my problems with the new --link-by-hash stuff (all previous tests were on unpatched master). At least I now know most of the problems I thought I was seeing with --link-by-hash were actually because of --debug=all! Oh well, I guess I'll have to start using explicit debug flags. Cheers, Chris -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
