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-3536] Memory leak with String.range(options: .regularExpression) #4303
Comments
Looks like a general leak in NSCache, independent of the type. {{ 1> import Foundation 6> for _ in 1...10000 { |
Here's a view of the cache from the command line, with Swift 3.0.2 on Ubuntu 16.04. There are repeated key/value with the same thing, if they have been set in the cache. I would have expected (a) this not to happen, and (b) even if it did store duplicates for it to start evicting after the countLimit was reached. The hypothesis is that the String.range cache of Regex is hitting this same issue with the cache in some way: [254] = { |
Interestingly, it doesnt' look like the lookup works for String values. > var c = NSCache<NSString,NSString> |
So if you have two NSString instances, with the same value, then they don't get looked up properly from NSCache: Welcome to Swift version 3.0.2 (swift-3.0.2-RELEASE). Type :help for assistance. If you use the same instance, then it works: 8> c.object(forKey:k1) |
Further observation: the NSCache only works iff the keys are unique. It looks like they are hashing based on the memory address of the key, which means it will work for static constants but not for dynamically generated strings. open func object(forKey key: KeyType) -> ObjectType? { let keyRef = unsafeBitCast(key, to: UnsafeRawPointer.self) _lock.lock() return object Suggestion would be to remove the caching from the regular expression lookup until a correct implementation can be found. |
Comment by Nethra Ravindran (JIRA) Raised the PR for this issue - #876 |
This looks to be resolved since at least 4.2 as no leaks are seen with valgrind anymore |
Environment
Linux (Ubuntu 14.04), Swift 3.0.2 release
Additional Detail from JIRA
md5: 42f6ad73e1163758bff04e137daf6d8c
cloned to:
Issue Description:
There appears to be a memory leak on Linux when searching for a substring of a String using a regular expression. The following code leaks around 18mb (roughly 1800 bytes per call to
String.range
):It seems to be specific to the use of regular expressions. Using (for example)
options: .caseInsensitive
does not leak.The same code also does not leak on Mac.
The text was updated successfully, but these errors were encountered: