At the request of @alblue I tried a couple of tests to narrow things down. Adding an extra call to sum with a [UInt8] does not leak extra memory. Neither does looping around the code.

In fact I have a simpler repro. The following Swift file also leaks in the same way:

import Foundation

let data = Data(base64Encoded: "UE9TVCAvIEhUVFAvMS4wDQpDb250ZW50LUxlbmd0aDoNCg0K")!
print(data.count)

Some bisects on the Swift 4.1 nightlies reveal that swift-4.1-DEVELOPMENT-SNAPSHOT-2017-12-04 is fine, and swift-4.1-DEVELOPMENT-SNAPSHOT-2017-12-07 fails. So the bad change was introduced in that window.

Ok, let's remove Foundation from our list of possible culprits, as the following definitely minimal repro also exhibits the same leak:

protocol P { }
let x: Any = 1
let y = x as? P

I think at this point we can call this either a compiler or standard library bug.

@swift-ci create

The runtime does need to allocate memory in _registerProtocolProtocols to track the sections in which it can find protocol conformances. That'll happen the first time one dynamically queries conformances (e.g., triggered here by the "as? P"), as well as any time one dlopen's another shared library. We hold on to the memory forever because we may need to rescan these sections later on. The actual allocations here should be very few, so if we're seeing a lot of growth here that would be a bug. However, it looks like something where we need to whitelist these allocations as intentionally never freed.

@DougGregor Are you sure that's what's happening here?

Both valgrind and ASAN are adamant that the allocations are entirely lost: that is, they're heap-allocated and there are no pointers remaining to them. That's not quite the same as "allocating but never freeing": it's "allocating and then losing".

Put another way: older versions of the runtime on Linux do not trip this issue, and the Darwin runtime does not either.

Oh, they're entirely lost. That is indeed bad!

And now I see the "definitely lost"; sorry for jumping the gun here.

No problem, it took me a while to convince myself this was a real problem too.

FWIW, I should stress that this isn't a particularly high-urgency leak, unlike SR-6849. The size of the leak in this case is small: in all my tests I've never seen it leak more than 64 bytes. This doesn't pose a threat to any running programs, obviously

This bit of code over at https://github.com/apple/swift/blob/master/stdlib/public/runtime/ProtocolConformance.cpp#L291-L293 is potential suspicious:

  // Conformance cache should always be sufficiently initialized by this point.
  _registerProtocolConformances(Conformances.unsafeGetAlreadyInitialized(),
                                recordsBegin, recordsEnd);

It's plausible that, with ELF, we're getting into this code (addImageProtocolConformanceBlockCallback) before the Conformances table gets initialized. I'm not set up to easily test this at the moment, but I'd want to try changing this to:

// Conformance cache should always be sufficiently initialized by this point.
  _registerProtocolConformances(Conformances.get(), recordsBegin, recordsEnd);