[swift-users] Why does this leak?

Rick Aurbach rlaurb at icloud.com
Mon Mar 27 15:31:04 CDT 2017


Okay, I downloaded the latest Xcode from the developer site. (The download page said it was 8.3beta5, but the version info called it 8.3 (8E161).)

So I put the use of the enum back into my code and profiled it again. (Please refer to my original post for the Case 1 code that I’m testing here.)

According to the Leaks Instrument, there is still a leak (just one 32-byte block, rather than two) coming from the call to prepare.

Unless I’m missing something REALLY basic here, using the enum as in my original post should not leak. (Right??) So either there is a compiler issue (still present in the compiler version of Xcode 8E161) or there is an issue in the Leaks Instrument (still present in the latest Xcode).

This is frustrating, because I don’t want to release a product with known leaks, but I don’t really know at this point whether I have one or whether I’m just seeing an artifact. Suggestions??

Cheers,

Rick Aurbach

> On Mar 27, 2017, at 3:01 AM, Alex Blewitt <alblue at apple.com> wrote:
> 
> 
>> On 26 Mar 2017, at 18:43, Rick Aurbach via swift-users <swift-users at swift.org> wrote:
>> 
>> I have a situation where I have a leak that I do not understand. I would be very grateful if someone could explain it to me and offer an idea of how I can make the pattern work without leaking:
> 
> How are you determining that this is leaking? There was an issue in Xcode where the 'leaks' detector was unable to introspect the memory layout of a Swift object containing an enum stored property and incorrectly flagging other such reachable objects as leaks. If that's the case, do you still see the same behaviour flagged in the latest Xcode?
> 
> Alex
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170327/43e70ddd/attachment.html>


More information about the swift-users mailing list