rsync crashes: malloc error: "pointer being freed was not allocated"

[Polyergic (Shad Sterling)]

After upgrading to El Capitan and restoring most previously installed ports, rsync @3.1.2_0 crashes when attempting to sync (pulling remote files), e.g.:

rsync(914,0x7fff75de7000) malloc: *** error for object 0x7fb853406cb0: pointer being freed was not allocated

rsync(919,0x7fff75de7000) malloc: *** error for object 0x7f8052500ea0: pointer being freed was not allocated

Remote server is CentOS 6.7, rsync 3.0.6-12.el6

[ryandesign (Ryan Carsten Schmidt)]

Can you provide a reproduction recipe—a command I can run on my system to see the same crash?

Can you attach the crash log file OS X generated?

[cameron.layne@…]

I have the same problem.

For me, it appears when I add the 'X' rsync option to copy extended attributes.

# Successful case
# -------------------
$ rsync -aP remoteserver:/sample-data .
receiving incremental file list
sample-data/
sample-data/foo.txt
              7 100%    6.84kB/s    0:00:00 (xfr#1, to-chk=2/4)
sample-data/hello.txt
             14 100%   13.67kB/s    0:00:00 (xfr#2, to-chk=1/4)
sample-data/mydate.txt
             29 100%   28.32kB/s    0:00:00 (xfr#3, to-chk=0/4)

# Now the error
# -------------------
$ rsync -aXP remoteserver:/sample-data .
receiving incremental file list
sample-data/
sample-data/foo.txt
              7 100%    6.84kB/s    0:00:00 (xfr#1, to-chk=2/4)
sample-data/hello.txt
             14 100%   13.67kB/s    0:00:00 (xfr#2, to-chk=1/4)
rsync(2689,0x7fff7bbac300) malloc: *** error for object 0x7fa300600070: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
rsync: connection unexpectedly closed (157 bytes received so far) [generator]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [generator=3.1.2]

$ port installed rsync
The following ports are currently installed:
  rsync @3.1.1_0
  rsync @3.1.2_0 (active)
$ rsync --version
rsync  version 3.1.2  protocol version 31

[Polyergic (Shad Sterling)]

I habitually run rsync as rsync -rlHpEAXtSyzP --delete; sure enough, when I reduce it to rsync -rlHpEAtSyzP --delete it works.

How do I find the crash log files OS X generates?

[cameron.layne@…]

Look in the Console app (/Applications/Utilities) under User Diagnostic Reports.

[cameron.layne@…]

Cc Me!

[davidfavor (David Favor)]

This bug is easy to reproduce.

Seems like the bug only occurs when the source is a Linux system with extended attributes set on a file/directory.

Fix right now appears to be removing -X when rsync'ing between disparate OS types, like Linux + OSX.

Linux to Linux seems to work fine + OSX to OSX seems to work fine.

[Polyergic (Shad Sterling)]

Thanks David!

Is this an upstream bug, or does the port do something that might introduce the problem?

[ryandesign (Ryan Carsten Schmidt)]

Is this still a problem with rsync 3.2.1? If so, please report it to the developers of rsync. We are using some patches in the rsync port, but I believe they are from the set of official upstream patches.

[ShadSterling (Shad Sterling)]

Since then I don't routinely invoke rsync directly anymore, but after restoring the -X to my scripts and waiting for all of the cronjobs to fire I don't see any occurrences of the error. I'm on rsync @3.1.3_0, so I guess I'm behind on updates, but unless it's reintroduced by 3.2.1 it looks to me like it's been fixed.

[kencu (Ken)]

That error:

malloc: *** error for object 0x7fa300600070: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

is the exact error you see when there is a ABI mixup between the system libstdc++ and macports libstdc++ when using libgcc.

My (incomplete) understanding of why this error occurs is that an object is created by one of the libraries, held by the application for some period of time I presume, and then passed off to the other library to release. But the ABI issue makes the release fail.

Whether that applies in this case, I can't be sure.