Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-3966] Linux MutableData.append() memory leak in 3.1 Snapshots #4104

swift-ci opened this issue Feb 15, 2017 · 3 comments

[SR-3966] Linux MutableData.append() memory leak in 3.1 Snapshots #4104

swift-ci opened this issue Feb 15, 2017 · 3 comments


Copy link

@swift-ci swift-ci commented Feb 15, 2017

Previous ID SR-3966
Radar None
Original Reporter carlb (JIRA User)
Type Bug
Status Resolved
Resolution Done

Attachment: Download


ubuntu@ubuntu-yakkety:~$ swift --version
Swift version 3.1-dev (LLVM a7c680da51, Clang f186e73135, Swift 5c7823ca8c)
Target: x86_64-unknown-linux-gnu
ubuntu@ubuntu-yakkety:~$ uname -a
Linux ubuntu-yakkety 4.8.0-37-generic #39-Ubuntu SMP Thu Jan 26 02:27:07 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Additional Detail from JIRA
Votes 1
Component/s Foundation
Labels Bug, 3.1Regression, Leak, Linux
Assignee saiHema (JIRA)
Priority Medium

md5: 786a9cce487d231f6c1fea6bba5f4fb2

Issue Description:

Running a simple loop that creates `NSMutableData` objects and appends to them, I get a pretty obvious memory leak (according to `ps` and `valgrind`) under `swift-3.1-DEVELOPMENT-SNAPSHOT-2017-02-14-a-ubuntu16.10` `Swift version 3.1-dev (LLVM a7c680da51, Clang f186e73135, Swift 5c7823ca8c)`.

This did not happen under 3.0.2.

Code attached, but it basically:
for i in 0..<100 {
var fileData = NSData(contentsOfFile: "/usr/lib/git-core/git")
if let fileData = fileData {
var fileDoubleData: NSMutableData = NSMutableData(bytes:fileData.bytes, length:fileData.length)
fileDoubleData.append(fileData.bytes, length:fileData.length)
`valgrind --tool=memcheck` says:
==7402== 247,463,936 bytes in 59 blocks are definitely lost in loss record 28 of 28
==7402== at 0x4C2ED5F: realloc (in /usr/lib/valgrind/
==7402== by 0x54EC372: __CFDataGrow (in /usr/lib/swift/linux/
==7402== by 0x54EBBE9: CFDataReplaceBytes (in /usr/lib/swift/linux/
==7402== by 0x5687C65: Foundation.NSMutableData.append (Swift.UnsafeRawPointer, length : Swift.Int) -> () (in /usr/lib/swift/linux/
==7402== by 0x401491: main (in /home/ubuntu/mem_test)

output from `valgrind --tool=memcheck` and `valgrind --tool=massif` also attached.

Copy link

@drewcrawford drewcrawford commented Feb 17, 2017

I think this is because

} else {
            if let handler = deallocator {
                _deallocHandler!.handler = handler
            // The data initialization should flag that CF should not deallocate which leaves the handler a chance to deallocate instead
            _CFDataInit(unsafeBitCast(self, to: CFMutableData.self), options | __kCFDontDeallocate, length, bytePtr, length, true)

In the case that deallocator == nil, A) handler is not set, and B) CF is instructed not to deallocate. Therefore nobody will clean this up.

deallocator is apparently nil in many of the convenience constructors, including the one in the repro case

Copy link
Contributor Author

@swift-ci swift-ci commented Feb 27, 2017

Comment by Carl Brown (JIRA)

Code to fix this was merged in #896 and #890

Copy link
Contributor Author

@swift-ci swift-ci commented Mar 2, 2017

Comment by sai Hema k (JIRA)

PR merged

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 5, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

2 participants