Which rsync version?

[Matt McCutchen]

On 8/3/07, Sven.Hartrumpf at fernuni-hagen.de
<Sven.Hartrumpf at fernuni-hagen.de> wrote:
> Thanks. Now gdb's output it might be more useful?
>
> (gdb) show follow-fork-mode
> Debugger response to a program call of fork or vfork is "parent".
> (gdb) set follow-fork-mode child
> (gdb) show follow-fork-mode
> Debugger response to a program call of fork or vfork is "child".
> (gdb) run -a --progress -v /cl/ /data/cl
> Starting program: /programs/linux/rsync-3.0.0-64/bin/rsync -a --progress -v /cl/ /data/cl
> sending incremental file list
> Program received signal SIGPIPE, Broken pipe.
> [Switching to process 18620]
> 0x00002b89a0b4c280 in __write_nocancel () from /lib64/libc.so.6
> (gdb) bt
> #0  0x00002b89a0b4c280 in __write_nocancel () from /lib64/libc.so.6
> #1  0x0000000000420acc in writefd_unbuffered (fd=7,
>     buf=0x66cb20 "8n&/schulorganisation,property=source.txt", len=2122)
>     at io.c:1387
> #2  0x000000000042126a in io_flush (flush_it_all=1) at io.c:1442
> #3  0x0000000000409c8c in read_ndx_and_attrs (f_in=0,
>     iflag_ptr=0x7fff0a2284c8, type_ptr=0x7fff0a2284cf "",
>     buf=0x7fff0a2263d0 "", len_ptr=0x7fff0a2284c4) at rsync.c:184
> #4  0x000000000040f18e in recv_files (f_in=0, local_name=0x0) at receiver.c:371
> #5  0x0000000000416f39 in do_recv (f_in=0, f_out=1, local_name=0x0)
>     at main.c:726
> #6  0x00000000004177cd in start_server (f_in=0, f_out=1, argc=1,
>     argv=0x7fff0a229638) at main.c:884
> #7  0x0000000000418875 in child_main (argc=2122, argv=0xffffffffffffffff)
>     at main.c:891
> #8  0x000000000042af95 in local_child (argc=2, argv=0x7fff0a229630,
>     f_in=0x7fff0a22b61c, f_out=0x7fff0a22b618,
>     child_main=0x418860 <child_main>) at pipe.c:147
> #9  0x000000000041817b in main (argc=2, argv=0x66c9b0) at main.c:445
> (gdb)

No, that's just another SIGPIPE.  There are a total of three rsync
processes, forked in the following pattern:

sender
 \_ generator
      \_ receiver

Your first backtrace was for the sender.  Setting gdb to always follow
the child gave you the backtrace for the receiver.  But the generator
is the one that is crashing and taking the others down with it.

To trace the generator, try `set follow-fork-mode ask'.  When you are
asked about the first fork, choose the child (the generator).  When
you are asked about the second, stick with the parent (the generator).
 If your gdb doesn't support `set follow-fork-mode ask' (mine
doesn't), you can set a catchpoint on the fork to give you the
opportunity to change the follow-fork-mode from child to parent, like
this:

[matt at mattlaptop2 test]$ gdb rsync
GNU gdb Red Hat Linux (6.6-15.fc7rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...
(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) catch fork
Catchpoint 1 (fork)
(gdb) run -rni src/ dest/
Starting program: /usr/bin/rsync -rni src/ dest/
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Catchpoint 1 (forked process 2957), 0x00110402 in __kernel_vsyscall ()
(gdb) set follow-fork-mode child
(gdb) continue
Continuing.
[New process 2957]
[Switching to process 2957]

Catchpoint 1 (forked process 2958), 0x00110402 in __kernel_vsyscall ()
(gdb) set follow-fork-mode parent
(gdb) continue
Continuing.
[Detaching after fork from child process 2958. (Try `set detach-on-fork off'.)]
skipping non-regular file "bar"
skipping non-regular file "baz"

Program exited normally.
(gdb) quit

Of course, you'll get a crash instead of "Program exited normally".

Matt