<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">I think there is probably some likely issue with the fact that NSMutableData is a subclass and the layout initialization is not properly setup during the init for that object.</div><div class=""><br class=""></div><div class="">__kCFDontDeallocate is used to mark the allocated memory as managed by the deallocator blocks. So I bet the problem is that the code-path for NSMutableData(capacity: 0) is hitting the don’t deallocate code path incorrectly (where as the other versions are hitting the appropriate flagging; hence the crashes)</div><div class=""><br class=""></div><div class="">Does this also occur in the Darwin builds of this? (Using SwiftFoundtion instead of Foundation)</div><br class=""><div><blockquote type="cite" class=""><div class="">On May 16, 2016, at 9:34 AM, Ian Partridge via swift-corelibs-dev <<a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><pre style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:11.9px;margin-top:0px;margin-bottom:0px;font-stretch:normal;line-height:1.45;padding:16px;overflow:auto;border-radius:3px;word-wrap:normal;color:rgb(51,51,51);background-color:rgb(247,247,247)" class=""><span class="" style="color:rgb(167,29,93)">import</span> <span class="" style="color:rgb(0,134,179)">Foundation</span>
<span class="" style="color:rgb(167,29,93)">while</span> <span class="" style="color:rgb(0,134,179)">true</span> {
<span class="" style="color:rgb(167,29,93)">var</span> myData: NSMutableData? <span class="" style="color:rgb(167,29,93)">=</span> NSMutableData(capacity: <span class="" style="color:rgb(0,134,179)">0</span>)
myData <span class="" style="color:rgb(167,29,93)">=</span> <span class="" style="color:rgb(0,134,179)">nil</span>
}</pre><div class=""><br class=""></div><div class="">Running this infinite loop with swift-corelibs-foundation shows a steady memory leak, with the process's RSS increasing over time. No leak is seen with Foundation on Darwin.</div><div class=""><br class=""></div><div class="">Instrumenting with Valgrind's massif profiler shows this stacktrace is responsible for the leak:</div><div class=""><br class=""></div><div class=""><pre style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:11.9px;margin-top:0px;margin-bottom:16px;font-stretch:normal;line-height:1.45;padding:16px;overflow:auto;border-radius:3px;word-wrap:normal;color:rgb(51,51,51);background-color:rgb(247,247,247)" class=""><code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:11.9px;padding:0px;margin:0px;border-radius:3px;border:0px;display:inline;max-width:initial;overflow:initial;line-height:inherit;word-wrap:normal;background:transparent" class="">67.36% (114,349B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
->65.01% (110,352B) 0x59F7A89: _CFDataInit
->65.01% (110,352B) 0x5B8A8DF: _TTSf4n_n_n_g_n___TFC10Foundation6NSDatacfT5bytesGSqGSpT___6lengthSi4copySb11deallocatorGSqFTGSpT__Si_T___S0_
->65.01% (110,352B) 0x5B873ED: _TFC10Foundation13NSMutableDataCfT8capacitySi_GSqS0__
->65.01% (110,352B) 0x40105D: main</code></pre></div><div class="">I've stepped through the code with a debugger and observed that the requested capacity is <a href="https://github.com/apple/swift-corelibs-foundation/blob/df239bbbdf5bcdd9ea31c394c6af4dd7c328f99d/Foundation/NSData.swift#L904" class="">thrown away</a> [1] to begin with. The leak occurs regardless of the capacity requested.</div><div class=""><br class=""></div><div class="">The deinitializer for NSData does call through to _CFDeinit(), which does then call the <a href="https://github.com/apple/swift-corelibs-foundation/blob/ea6179dd35be2c7d9a8f953579f626a5f1be6511/CoreFoundation/Base.subproj/CFRuntime.c#L1773" class="">finalize()</a> [2] function and hence through to <a href="https://github.com/apple/swift-corelibs-foundation/blob/ea3014bd7883e428727272118cbf37dc56522be6/CoreFoundation/Collections.subproj/CFData.c#L294" class="">__CFDataDeallocate()</a> [3]. However, once in __CFDataDeallocate(), the code to free the buffer is skipped, because __kCFDontDeallocate is set.</div><div class=""><br class=""></div><div class="">If I hack _CFDataInit() so that __kCFDontDeallocate isn't set (by commenting out <a href="https://github.com/apple/swift-corelibs-foundation/blob/ea3014bd7883e428727272118cbf37dc56522be6/CoreFoundation/Collections.subproj/CFData.c#L337" class="">this line</a> [4]) then I get crashes elsewhere - so this obviously isn't the right approach.</div><div class=""><br class=""></div><div class="">I can see that some work has been <a href="https://github.com/apple/swift-corelibs-foundation/commit/ea3014bd7883e428727272118cbf37dc56522be6" class="">done in this area</a> [5] previously by Philippe so I'm wondering if anyone can advise on what might be going on here?</div><div class=""><br class=""></div><div class="">The init?(length:) initializer avoids CFData entirely and calls malloc() and free() directly. I'm not sure why that approach was taken and whether it's relevant to my issue.</div><div class=""><br class=""></div><div class="">Any help would be gratefully received!</div><div class=""><br class=""></div><div class="">Thanks,</div><div class=""><br class=""></div>[1] <a href="https://github.com/apple/swift-corelibs-foundation/blob/df239bbbdf5bcdd9ea31c394c6af4dd7c328f99d/Foundation/NSData.swift#L904" class="">https://github.com/apple/swift-corelibs-foundation/blob/df239bbbdf5bcdd9ea31c394c6af4dd7c328f99d/Foundation/NSData.swift#L904</a><div class="">[2] <a href="https://github.com/apple/swift-corelibs-foundation/blob/ea6179dd35be2c7d9a8f953579f626a5f1be6511/CoreFoundation/Base.subproj/CFRuntime.c#L1773" class="">https://github.com/apple/swift-corelibs-foundation/blob/ea6179dd35be2c7d9a8f953579f626a5f1be6511/CoreFoundation/Base.subproj/CFRuntime.c#L1773</a></div><div class="">[3] <a href="https://github.com/apple/swift-corelibs-foundation/blob/ea3014bd7883e428727272118cbf37dc56522be6/CoreFoundation/Collections.subproj/CFData.c#L294" class="">https://github.com/apple/swift-corelibs-foundation/blob/ea3014bd7883e428727272118cbf37dc56522be6/CoreFoundation/Collections.subproj/CFData.c#L294</a><br class=""><div class="">[4] <a href="https://github.com/apple/swift-corelibs-foundation/blob/ea3014bd7883e428727272118cbf37dc56522be6/CoreFoundation/Collections.subproj/CFData.c#L337" class="">https://github.com/apple/swift-corelibs-foundation/blob/ea3014bd7883e428727272118cbf37dc56522be6/CoreFoundation/Collections.subproj/CFData.c#L337</a></div><div class="">[5] <a href="https://github.com/apple/swift-corelibs-foundation/commit/ea3014bd7883e428727272118cbf37dc56522be6" class="">https://github.com/apple/swift-corelibs-foundation/commit/ea3014bd7883e428727272118cbf37dc56522be6</a><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature">Ian Partridge<br class=""></div>
<br class=""></div></div></div>
_______________________________________________<br class="">swift-corelibs-dev mailing list<br class=""><a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-corelibs-dev<br class=""></div></blockquote></div><br class=""></body></html>