search for: client_run

...send_files phase=1 +recv_files(1) starting recv_files(y) got file_sum * +renaming .y.Oq45md to y recv_files phase=1 generate_files phase=2 send_files phase=2 @@ -43,9 +44,9 @@ recv_files finished generate_files phase=3 generate_files finished -client_run waiting on 18876 +client_run waiting on 18878 -sent 75 bytes received 533 bytes 1,216.00 bytes/sec +sent 75 bytes received 561 bytes 424.00 bytes/sec total size is 0 speedup is 0.00 [sender] _exit_cleanup(code=0, file=main.c, line=1196): entered [sender] _exit_clean...

...missing here> send_files phase=1 recv_files phase=1 generate_files phase=2 send_files phase=2 send files finished total: matches=0 hash_hits=0 false_alarms=0 data=0 recv_files phase=2 recv_files finished generate_files phase=3 generate_files finished client_run waiting on 9125 sent 96 bytes received 874 bytes 1,940.00 bytes/sec total size is 0 speedup is 0.00 [sender] _exit_cleanup(code=0, file=main.c, line=1196): entered [sender] _exit_cleanup(code=0, file=main.c, line=1196): about to call exit(0) Best regards from Dresden/German...

...nment and it sometime will crash and leave a core dump file. from core dump, gdb shows that gdb) bt #0 add_dirs_to_tree (parent_ndx=-1, from_flist=0x56c590, dir_cnt=1) at flist.c:1422 #1 0x0000000000409eab in send_file_list (f=16, argc=-1, argv=0x56c238) at flist.c:2068 #2 0x0000000000419052 in client_run (f_in=16, f_out=16, pid=-1, argc=1, argv=0x56c230) at main.c:1033 #3 0x000000000041a09a in main (argc=2, argv=0x56c230) at main.c:1260 (gdb) bt f #0 add_dirs_to_tree (parent_ndx=-1, from_flist=0x56c590, dir_cnt=1) at flist.c:1422 file = (struct file_struct *) 0x0 ~~~~it crashes at add_...

...ot;rsync.core") at backup.c:266 #1 0x80537c9 in make_backup (fname=0x808f060 "rsync.core") at backup.c:297 #2 0x804c003 in delete_files (flist=0x8096100) at receiver.c:112 #3 0x805028c in do_recv (f_in=3, f_out=3, flist=0x8096100, local_name=0x0) at main.c:434 #4 0x805093c in client_run (f_in=3, f_out=3, pid=-1, argc=1, argv=0x8095004) at main.c:666 (gdb) p *file $1 = {modtime = 1076386251, length = 577536, mode = 33152, u = {rdev = 0, sum = 0x0, link = 0x0}, link_u = {idev = 0x80d1734, links = 0x80d1734}, basename = 0x80d1744 "rsync.core", dirname = 0x0, ba...

...; + extern int force_f_in; + extern int force_f_out; int rc; /* Don't clobber argv[] so that ps(1) can still show the right @@ -770,9 +772,14 @@ list_only = 1; } - pid = do_cmd(shell_cmd,shell_machine,shell_user,shell_path,&f_in,&f_out); + if (force_f_in != -1) { + ret = client_run(force_f_in, force_f_out, -1, argc, argv); + } + else { + pid = do_cmd(shell_cmd,shell_machine,shell_user,shell_path,&f_in,&f_out); - ret = client_run(f_in, f_out, pid, argc, argv); + ret = client_run(f_in, f_out, pid, argc, argv); + } fflush(stdout); fflush(stderr); diff -urN r...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm playing with valgrind, and ran it with rsync. I'm really not sure if I'm understanding either the tool or the code, but here is an example. When we're downloading a file in client-server mode, we end up in main.c::client_run(), doing a call to flist.c::recv_file_list(). Around line 1036, we do a malloc of the file list: flist = (struct file_list *) malloc(sizeof(flist[0])); and return flist. Then we go on to use flist->, but there doesn't ever appear to be a free of that memory. client_run() returns,...

...cations of rsync with a timeout die based on that timeout: wait_process() could call check_timeout() before calling msleep(). When the timeout has been exceeded, rsync would call _exit_cleanup and kill_all would take care of the child. You could make this check optional so that only calls from client_run do the check. just a thought. -- david ahern

Hi. We sometimes/often get such errors. It occures in main.c/client_run(). I investigated further and found, that the waitpid() in main.c/wait_process() exits with -1, errno = ECHILD, which means "No children". *status can contain garbage in such cases - but not always. It happens under Solaris-2.5.1/SPARC. It (ECHILD) also happens on other Solaris versions -...

...tastructures()". Now, batch code is essentially de-coupled from the rest of rsync. Points of interaction are: 1) opening a batch file in main() 2) a hook in readfd() for writing batches from a receiver 3) a hook in writefd() for writing batches from a sender 4) file descriptor swaping in client_run() for reading batches 5) aborting the unneeded server in local_child() during a read_batch 6) a special-case for writing the protocol version during an rsyncd inband exchange 7) a special-case for writing the checksum-seed 8) a special-case for not reading end-of-run statistics Points 1-5...

...ff348 "????", N=4) at io.c:316 #5 0x24998 in read_int (f=6) at io.c:329 #6 0x184e8 in generate_files (f=5, flist=0x57520, local_name=0x0, f_recv=6) at generator.c:471 #7 0x1d3fc in do_recv (f_in=4, f_out=5, flist=0x57520, local_name=0x0) at main.c:379 #8 0x1d958 in client_run (f_in=4, f_out=5, pid=22226, argc=1, argv=0x56f74) at main.c:558 #9 0x1ddc0 in start_client (argc=1, argv=0x56f74) at main.c:731 #10 0x1e098 in main (argc=2, argv=0x56f70) at main.c:841 Backtrace #2 on client (child): #0 0xef5b7904 in _poll () #1 0xef5d3d40 in _select () #2 0x...

...recv_files(y) > got file_sum > * +renaming .y.Oq45md to y > recv_files phase=1 > generate_files phase=2 > send_files phase=2 > @@ -43,9 +44,9 @@ > recv_files finished > generate_files phase=3 > generate_files finished > -client_run waiting on 18876 > +client_run waiting on 18878 > > -sent 75 bytes received 533 bytes 1,216.00 bytes/sec > +sent 75 bytes received 561 bytes 424.00 bytes/sec > total size is 0 speedup is 0.00 > [sender] _exit_cleanup(code=0, file=main.c, line=1196): ent...

...ly should be doing buffering! It looks like there's a function io_start_buffering() that should be called. I don't know why it isn't called until later, though, and there may be a good reason. It's getting called in send_file_list() and in do_recv(), both of which are called from client_run() in main.c after send_exclude_list(). Could you play with calling it before send_exclude_list()? You're sending the list from the receiver to the sender so you're in the second half client_run(), the do_recv() part. You may possibly need to call io_flush() more often, although I don'...

...0010002da8c in read_msg_fd () at io.c:338 #5 0x000000010002e7b4 in wait_for_receiver () at io.c:540 #6 0x00000001000132f8 in generate_files (f_out=4, local_name=0x0) at generator.c:2290 #7 0x0000000100020f48 in do_recv (f_in=5, f_out=4, local_name=0x0) at main.c:833 #8 0x000000010002179f in client_run (f_in=5, f_out=4, pid=64758, argc=1, argv=0x100100398) at main.c:1070 #9 0x00000001000220ff in start_client (argc=1, argv=0x100100398) at main.c:1277 #10 0x00000001000227ea in main (argc=2, argv=0x100100390) at main.c:1504 Stack trace on the iMac for the child rsync process (gdb) bt #0 0x0...

...555585cfe in read_buf (f=f at entry=1606, buf=buf at entry=0x7fffffffa810 "\037", len=len at entry=4) at io.c:1815 #8 0x0000555555585ef6 in read_int (f=f at entry=1606) at io.c:1711 #9 0x00005555555876ed in setup_protocol (f_out=1605, f_in=1606) at compat.c:158 #10 0x0000555555576417 in client_run (f_in=1606, f_out=1605, pid=24793, argc=1, argv=0x5555557d5240) at main.c:1128 #11 0x000055555557795e in start_client (argv=0x5555557d5240, argc=1) at main.c:1423 #12 main (argc=2, argv=0x5555557d5240) at main.c:1651 It looks like a bug, but I'm not sure) -- Boris

...3C602: get_xattr (xattrs.c:309) by 0x4076EF: send_file_name (flist.c:1433) by 0x40817D: send_directory (flist.c:1673) by 0x408991: send1extra (flist.c:1827) by 0x408D23: send_extra_file_list (flist.c:1899) by 0x417345: send_files (sender.c:184) by 0x42110A: client_run (main.c:1039) by 0x421B9B: start_client (main.c:1287) - There is another unrelated leak at much lower rate; 109 bytes in 39 blocks are definitely lost in loss record 17 of 30 at 0x4A05E46: malloc (vg_replace_malloc.c:195) by 0x41DF8F: _new_array (util.c:1430) by...

...;????X???\034?\004\b\006", N=4) at io.c:327 #3 0x8056d7f in read_int (f=6) at io.c:342 #4 0x804b71c in generate_files (f=4, flist=0x807fba8, local_name=0x0, f_recv=6) at generator.c:524 #5 0x805022f in do_recv (f_in=5, f_out=4, flist=0x807fba8, local_name=0x0) at main.c:420 #6 0x80506e4 in client_run (f_in=5, f_out=4, pid=7277, argc=1, argv=0x807f96c) at main.c:599 #7 0x8050ad3 in start_client (argc=2, argv=0x807f968) at main.c:774 #8 0x8050d44 in main (argc=2, argv=0x807f968) at main.c:921 #9 0x4004e853 in __libc_start_main () from /lib/libc.so.6 If I then detach and attach to process numb...

...3 #4 0x00000000004294b7 in read_msg_fd () at io.c:346 #5 0x000000000041250f in generate_files (f_out=4, local_name=<value optimized out>) at generator.c:2366 #6 0x000000000041d24c in do_recv (f_in=<value optimized out>, f_out=4, local_name=0x0) at main.c:843 #7 0x000000000041d4a2 in client_run (f_in=0, f_out=4, pid=-1, argc=<value optimized out>, argv=0xcba240) at main.c:1080 #8 0x000000000041e2fd in start_client (argc=1, argv=0xcba240) at main.c:1287 #9 main (argc=1, argv=0xcba240) at main.c:1514 (gdb) backtrace #0 0x00007f14cf42c243 in __select_nocancel () at ../sysdeps/unix/...

...3 #4 0x00000000004294b7 in read_msg_fd () at io.c:346 #5 0x000000000041250f in generate_files (f_out=4, local_name=<value optimized out>) at generator.c:2366 #6 0x000000000041d24c in do_recv (f_in=<value optimized out>, f_out=4, local_name=0x0) at main.c:843 #7 0x000000000041d4a2 in client_run (f_in=0, f_out=4, pid=-1, argc=<value optimized out>, argv=0xcba240) at main.c:1080 #8 0x000000000041e2fd in start_client (argc=1, argv=0xcba240) at main.c:1287 #9 main (argc=1, argv=0xcba240) at main.c:1514 (gdb) backtrace #0 0x00007f14cf42c243 in __select_nocancel () at ../sysdeps/unix/...

...0x000000000040d252 in iconvbufs () #4 0x0000000000423bce in rwrite () #5 0x0000000000423505 in rprintf () #6 0x000000000042b911 in whine_about_eof () #7 0x000000000042f5e2 in read_buf () #8 0x000000000042fde1 in read_int () #9 0x000000000043055d in setup_protocol () #10 0x000000000041ffb8 in client_run () #11 0x00000000004209c6 in main () Please let us know if any additional information is needed for debugging. Regards, Balveer Singh -- You are receiving this mail because: You are the QA Contact for the bug.

I've been using 3.0.0pre8 to move a Debian archive from one filesystem to another. This archive contains a daily snapshot of the Debian ftp site, with common files hardlinked to save space. I noticed that it was using far more space than necessary. Upon investigation it seems that all the source files that have inode numbers greater than 2^31 aren't being hardlinked together at the