Opened 9 years ago

Last modified 3 years ago

#50350 assigned defect

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

Reported by: Polyergic (Shad Sterling) Owned by: ryandesign (Ryan Carsten Schmidt)
Priority: Normal Milestone:
Component: ports Version: 2.3.4
Keywords: Cc: jimjag (Jim Jagielski), cameron.layne@…, cooljeanius (Eric Gallager)
Port: rsync

Description

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

Attachments (5)

rsync-bug-reproduce.sh (497 bytes) - added by cameron.layne@… 9 years ago.
sample-data.tar.gz (269 bytes) - added by cameron.layne@… 9 years ago.
rsync_report1.crash (10.2 KB) - added by cameron.layne@… 9 years ago.
rsync_2016-01-24-211307_laconic.crash (10.5 KB) - added by Polyergic (Shad Sterling) 9 years ago.
rsync_2016-01-24-211309_laconic.crash (10.5 KB) - added by Polyergic (Shad Sterling) 9 years ago.

Download all attachments as: .zip

Change History (17)

comment:1 Changed 9 years ago by 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?

Changed 9 years ago by cameron.layne@…

Attachment: rsync-bug-reproduce.sh added

Changed 9 years ago by cameron.layne@…

Attachment: sample-data.tar.gz added

Changed 9 years ago by cameron.layne@…

Attachment: rsync_report1.crash added

comment:2 Changed 9 years ago by 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

comment:3 Changed 9 years ago by 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?

comment:4 Changed 9 years ago by cameron.layne@…

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

comment:5 Changed 9 years ago by cameron.layne@…

Cc: cameron.layne@… added

Cc Me!

Changed 9 years ago by Polyergic (Shad Sterling)

Changed 9 years ago by Polyergic (Shad Sterling)

comment:6 Changed 8 years ago by 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.

comment:7 Changed 8 years ago by Polyergic (Shad Sterling)

Thanks David!

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

comment:8 Changed 4 years ago by 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.

comment:9 Changed 4 years ago by 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.

comment:10 Changed 4 years ago by 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.

comment:11 Changed 4 years ago by mf2k (Frank Schima)

Owner: changed from macports-tickets@… to ryandesign
Status: newassigned

comment:12 Changed 3 years ago by cooljeanius (Eric Gallager)

Cc: cooljeanius added
Note: See TracTickets for help on using tickets.