Are you sure that the segmentation violation was in rsync, and not e.g. in the shell used to execute the backticks? Please provide a backtrace of the core dump.

I can't reproduce it on my system, I just get the usage message due to incomplete arguments.

Created attachment 6132 [details]
core dumped for rsync

I see what is happening.  options.c:1496:

backup_dir_remainder = sizeof backup_dir_buf - backup_dir_len;
if (backup_dir_remainder < 32) {
        snprintf(err_buf, sizeof err_buf,
                "the --backup-dir path is WAY too long.\n");
        return 0;
}

But backup_dir_remainder is unsigned, so the subtraction overflows and the error message does not trip.

There's also potential for a one-off overflow here:

  } else if (backup_dir_buf[backup_dir_len - 1] != '/') {
          backup_dir_buf[backup_dir_len++] = '/';
          backup_dir_buf[backup_dir_len] = '\0';
  }

backup_dir_len is incremented, but there is no corresponding decrement of backup_dir_remainder.

(In reply to comment #3)
> I see what is happening.  options.c:1496:
> 
> backup_dir_remainder = sizeof backup_dir_buf - backup_dir_len;
> if (backup_dir_remainder < 32) {
>         snprintf(err_buf, sizeof err_buf,
>                 "the --backup-dir path is WAY too long.\n");
>         return 0;
> }
> 
> But backup_dir_remainder is unsigned, so the subtraction overflows and the
> error message does not trip.

I would have expected strlcpy() to limit the return value to the bufsize passed as last argument, but at least the lib/compat.c version doesn't, and contradicts the comments there in doing so ("@return index of the terminating byte"). If it had done that, it would have limited the result of the subtraction to >= 0.

(In reply to comment #2)
> Created an attachment (id=6132) [details]
> core dumped for rsync

A coredump from your system is pretty useless for anyone else. That's why I asked for the backtrace from that coredump. However Matt has spotted the problem already.

Amusingly 'file core' says:

core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from '111111111111111'

Note how apparently argv[0] got overwritten as well.

Fix committed to git for both the crashing overflow and the off-by-one issue.