Odd bug with invalid memory address?

I’ve got the gdb backtrace and error below. It happens as soon as it starts to backup, this is the 2nd file it tries to snapshot. I’m not using lvm, so no snapshots. It’s not running out of memory, although htop does show a virtual usage of 768MB - would that be some limit I’m hitting. I have X files I’m trying to backup - could it be I’m just going over a limit there? This is from the 2.0.34 source code I downloaded yesterday from the urbackup website. I can reproduce this every time, but it doesn’t happen on any other box (I have over 30 boxes across 3 urbackup servers).

Any idea what I can do to fix this? Anything I can provide to help squash this bug?

GDB backtrace:

2016-10-28 02:20:55: Creating shadowcopy of ".symlink_nano" in indexDirs()
2016-10-28 02:20:55: ERROR: Creating snapshot of "/bin/nano" failed
2016-10-28 02:20:55: done.
2016-10-28 02:20:55: Backing up ".symlink_nano" without snapshot.
2016-10-28 02:20:55: Indexing ".symlink_nano"...
[New Thread 0x7fffecff9700 (LWP 3477)]
[New Thread 0x7fffed7fa700 (LWP 3476)]
[New Thread 0x7fffedffb700 (LWP 3468)]
[New Thread 0x7fffeeffd700 (LWP 3419)]
[New Thread 0x7fffef7fe700 (LWP 3418)]
[New Thread 0x7ffff4d5c700 (LWP 3416)]
[New Thread 0x7ffff555d700 (LWP 3415)]
[New Thread 0x7ffff5d5e700 (LWP 3414)]
[New Thread 0x7ffff655f700 (LWP 3413)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffeffff700 (LWP 3417)]
IndexThread::getAbsSymlinkTarget (this=this@entry=0x98c830, symlink="/bin/nano", orig_path="/bin",
    target=,
    output_target=) at urbackupclient/client.cpp:5710
5710            if (target.empty())
(gdb) bt
#0  IndexThread::getAbsSymlinkTarget (this=this@entry=0x98c830, symlink="/bin/nano", orig_path="/bin",
    target=,
    output_target=) at urbackupclient/client.cpp:5710
#1  0x00000000005d5d08 in IndexThread::convertToFileAndHash (this=this@entry=0x98c830, orig_dir="/bin", named_dir=".symlink_nano",
    files=std::vector of length 159, capacity 159 = {...}, fn_filter="nano") at urbackupclient/client.cpp:6013
#2  0x00000000005e070e in IndexThread::getFilesProxy (this=this@entry=0x98c830, orig_path="/bin", path="/bin", named_path=".symlink_nano",
    use_db=use_db@entry=false, fn_filter="nano", use_db_hashes=false) at urbackupclient/client.cpp:2078
#3  0x00000000005e15a2 in IndexThread::initialCheck (this=this@entry=0x98c830, volume="/bin/nano", vssvolume="/bin/nano", orig_dir="/bin",
    dir="/bin", named_path=".symlink_nano", outfile=..., first=true, flags=38, use_db=false, symlinked=true, depth=0)
    at urbackupclient/client.cpp:1615
#4  0x00000000005e59ae in IndexThread::indexDirs (this=this@entry=0x98c830, full_backup=full_backup@entry=true, simultaneous_other=false)
    at urbackupclient/client.cpp:1349
#5  0x00000000005e8cae in IndexThread::operator() (this=) at urbackupclient/client.cpp:619
#6  0x00000000004515cb in thread_helper_f (t=) at Server.cpp:1294
#7  0x00007ffff6c396aa in start_thread (arg=0x7fffeffff700) at pthread_create.c:333
#8  0x00007ffff696eeed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thanks for the bug report. This should fix the issue:

Yes, this fixes it and the backup runs successfully! Thank you.