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

Jump to bottom

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

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

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

swift-ci opened this issue Feb 15, 2017 · 3 comments
Labels
bug Foundation Leak Linux

Comments

@swift-ci
Copy link
Contributor

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

Attachment: Download

Environment

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/vgpreload_memcheck-amd64-linux.so)
==7402== by 0x54EC372: __CFDataGrow (in /usr/lib/swift/linux/libFoundation.so)
==7402== by 0x54EBBE9: CFDataReplaceBytes (in /usr/lib/swift/linux/libFoundation.so)
==7402== by 0x5687C65: Foundation.NSMutableData.append (Swift.UnsafeRawPointer, length : Swift.Int) -> () (in /usr/lib/swift/linux/libFoundation.so)
==7402== by 0x401491: main (in /home/ubuntu/mem_test)
```

output from `valgrind --tool=memcheck` and `valgrind --tool=massif` also attached.
@drewcrawford
Copy link
Contributor

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

@swift-ci
Copy link
Contributor Author

Comment by Carl Brown (JIRA)

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

@swift-ci
Copy link
Contributor Author

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
Assignees
No one assigned
Labels
bug Foundation Leak Linux
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@drewcrawford @swift-ci