[Bug 8308] rsync: exclude.c:532: change_local_filter_dir: Assertion `dir_depth < 4096/2+1' failed

samba-bugs at samba.org samba-bugs at samba.org
Tue Apr 8 19:31:50 MDT 2014


https://bugzilla.samba.org/show_bug.cgi?id=8308

--- Comment #1 from jss at mensa.org.au 2014-04-09 01:31:48 UTC ---
I also see this bug with the latest sources for: 3.1.1pre1 and i have a
directory tree i can reproduce this bug with easily, on a local machine. No
remote transfer required.

It is related to the --prune-empty-dirs option. Removing this from my command
line makes the error go away.

http://sourceforge.net/p/luckybackup/discussion/873564/thread/864b0b61/
"Indeed, rsync seems to bring this error up when specific filter rules
(include/exclude patterns) are used and then it tries to delete files at the
destination."

here is what gdb gives me (note, i have added some debug to the source and
recompiled, so line 623 in exclude.c was the assert statement at around line
613 in the original source:

Program received signal SIGABRT, Aborted.
0x0000003e66032925 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
64        return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) bt
#0  0x0000003e66032925 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x0000003e66034105 in abort () at abort.c:92
#2  0x0000003e6602ba4e in __assert_fail_base (fmt=<value optimized out>,
assertion=0x45073c "dir_depth < 4096/2+1", file=0x4505c1 "exclude.c",
    line=<value optimized out>, function=<value optimized out>) at assert.c:96
#3  0x0000003e6602bb10 in __assert_fail (assertion=0x45073c "dir_depth <
4096/2+1", file=0x4505c1 "exclude.c", line=623, function=0x450ca0
"change_local_filter_dir")
    at assert.c:105
#4  0x00000000004183d0 in change_local_filter_dir (dname=0x7fffffff8bb0
"contourd.ss/.Rational/Version_History/rivers/process_connection_utils.h,v",
dlen=73,
    dir_depth=3005) at exclude.c:623
#5  0x000000000040cd1b in do_delete_pass () at generator.c:362
#6  0x0000000000411fa3 in generate_files (f_out=1, local_name=<value optimized
out>) at generator.c:2180
#7  0x000000000041d161 in do_recv (f_in=<value optimized out>, f_out=1,
local_name=0x0) at main.c:945
#8  0x000000000041d7f5 in do_server_recv (f_in=0, f_out=1, argc=<value
optimized out>, argv=<value optimized out>) at main.c:1057
#9  start_server (f_in=0, f_out=1, argc=<value optimized out>, argv=<value
optimized out>) at main.c:1091
#10 0x000000000041d935 in child_main (argc=<value optimized out>, argv=<value
optimized out>) at main.c:1064
#11 0x00000000004380b8 in local_child (argc=2, argv=0x7fffffffae10,
f_in=0x7fffffffde7c, f_out=0x7fffffffde78, child_main=0x41d920 <child_main>) at
pipe.c:167
#12 0x000000000041bafa in do_cmd (cmd=<value optimized out>, machine=0x0,
user=<value optimized out>, remote_argv=<value optimized out>,
    remote_argc=<value optimized out>, f_in_p=0x7fffffffde7c,
f_out_p=0x7fffffffde78) at main.c:535
#13 0x000000000041e758 in start_client (argc=3, argv=0x680230) at main.c:1393
#14 main (argc=3, argv=0x680230) at main.c:1633

Note also, that in the source code, I've added this code directly above the
assert that triggers this failure:

    if ( dir_depth >= MAXPATHLEN/2+1 ) {
      rprintf(FINFO, "dname=[%s] dlen=[%d] dir_depth=[%d] cur_depth=[%d]
MAXPATHLEN/2+1=[%d] \n", dname, dlen, dir_depth, cur_depth, MAXPATHLEN/2+1);
    }

And this is never triggered. I have  therefore removed the if, and printed this
info unconditionally, and i find that the immediately before the assert fails,
dir_depth still only has a value of 1.

I have also noticed that sometimes the rsync aborts without actually triggering
the assert. And likewise, if the assert is removed, rsync still aborts at much
the same place in the code.

This all seems very odd to me. It's as if something is modifying the value of
dir_depth underneath this code... 


I am very rusty with my gdb usage - will try to get a breakpoint in and catch
it before it aborts and get some better info out of it.

-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.


More information about the rsync mailing list