# Swift 5.5 has serious stack corruption bugs!

**URL:** <https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344>\
**Category:** Compiler\
**Created:** [September 24, 2021, 10:23pm UTC](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344 "2021-09-24T22:23:24Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\
**Post date:** [September 24, 2021, 10:23pm UTC](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344/1 "2021-09-24T22:23:24Z")

</div>

hi all, I’ve discovered several stack corruption bugs related to `async`/`await` which can be reproduced in simple test programs compiled with recent nightly toolchains. **i have confirmed that ~~two~~  ~~three~~ four of these bugs are present in the 5.5-RELEASE toolchain.**

* * *

1. **stack corruption when using values returned by `async` closures**

```swift
// async-return-value-corruption.swift

@main 
enum Main 
{
    actor A
    {
        init() 
        {
        }
        
        func a(_ f:@Sendable () async -> (Int, (Int, Int, Int, Int))?) 
            async -> Void
        {
            guard let (head, tail):(Int, (Int, Int, Int, Int)) = await f()
            else 
            {
                return 
            }
            
            print((head, tail))
            return 
        }
    }
    
    static 
    func p() async -> Bool
    {
        true 
    }
    
    static 
    func main() async
    {
        while true 
        {
            let a:A = .init()
            
            async let task:Void = a.a
            {
                if await Self.p()
                {
                    return (0, (0, 0, 0 ,0)) 
                }
                else 
                {
                    return nil 
                }
            }
            await task
        }
    }
}

```

```nohighlight
$ swiftc --version
Swift version 5.5 (swift-5.5-RELEASE)
Target: x86_64-unknown-linux-gnu

$ swiftc -parse-as-library -O async-return-value-corruption.swift
$ ./async-return-value-corruption 

(139787763716080, (0, 0, 0, 0)) 
(139787629498352, (0, 0, 0, 0)) 
(139787965042672, (0, 0, 0, 0)) 
(139787763716080, (0, 0, 0, 0)) 
(139787629498352, (0, 0, 0, 0))
...

```

* * *

1. **segmentation faults when using `async let`**

```swift
// async-let-segfault.swift 
@main 
enum Main 
{
    static 
    func foo() async -> [Void]
    {
        try? await Task.sleep(nanoseconds: 1)
        return []
    }
    static 
    func main() async
    {
        async let task:Void = 
        {
            () async -> () in 
            try? await Task.sleep(nanoseconds: 1)
        }()
        while true 
        {
            let _:[Void] = await Self.foo()
        }
    }
}

```

```nohighlight
$ swiftc --version
Swift version 5.5 (swift-5.5-RELEASE)
Target: x86_64-unknown-linux-gnu

$ swiftc -O -parse-as-library async-let-segfault.swift 
async-let-segfault.swift:23:15: warning: will never be executed
        await task
              ^
async-let-segfault.swift:19:15: note: condition always evaluates to true
        while true 
              ^
$ ./async-let-segfault 
Segmentation fault (core dumped)

```

* * *

1. **stack corruption when passing enums to actor-isolated methods**

```swift
// async-stack-corruption.swift 

struct Users
{
    enum Access 
    {
        case guest
        case admin(Int)
        case developer(Int, Int, Int, Int)
    }
    actor State  
    {
        init()
        {
        }
        func set(permissions:(user:Int, access:Access?)) 
        {
            print(permissions)
        }
    }
    
    let state:State = .init()
    
    func set(permissions:(user:Int, access:Access?)) async 
    {
        await self.state.set(permissions: permissions)
    }
}
@main 
enum Main 
{
    static 
    func main() async
    {
        let users:Users = .init()
        let stream:AsyncStream<Int> = .init 
        {
            for i in 0 ..< 10
            {
                $0.yield(i) 
            }
            $0.finish()
        }
        for await i:Int in stream 
        {
            await users.set(permissions: (i, .guest))
        }
    }
}

```

```nohighlight
$ swiftc --version
Swift version 5.6-dev (LLVM ae102eaadf2d38c, Swift be2d00b32742678)
Target: x86_64-unknown-linux-gnu
$ swiftc -parse-as-library async-stack-corruption.swift 
$ ./async-stack-corruption 
(user: 0, access: Optional(main.Users.Access.admin(0)))
(user: 1, access: Optional(main.Users.Access.admin(0)))
(user: 2, access: Optional(main.Users.Access.admin(0)))
(user: 3, access: Optional(main.Users.Access.admin(0)))
(user: 4, access: Optional(main.Users.Access.admin(0)))
(user: 5, access: Optional(main.Users.Access.admin(0)))
(user: 6, access: Optional(main.Users.Access.admin(0)))
(user: 7, access: Optional(main.Users.Access.admin(0)))
(user: 8, access: Optional(main.Users.Access.admin(0)))
(user: 9, access: Optional(main.Users.Access.admin(0)))

```

i have encountered additional memory corruption bugs, including some weirdness with calling instance methods on actor-isolated properties ([thread](https://forums.swift.org/t/random-segfaults-with-async-await-but-only-on-release-builds/51832)), but these 3 are the issues i had time to isolate and reproduce this week. i have filed them as:

1. [SR-15225](https://bugs.swift.org/browse/SR-15225)
2. [SR-15241](https://bugs.swift.org/browse/SR-15241)
3. [SR-15240](https://bugs.swift.org/browse/SR-15240)

in my view, bug (1) is by far the most dangerous, as it occurs silently, and affects the 5.5 release toolchain. like bug (3), bug (1) also represents a _potential_ security vulnerability, though it is probably not easily exploitable in naturally occurring code.

(_update_) now that i’ve found that bug (3) _does occur in binaries built with the 5.5 release toolchain_, i am now even more concerned about bug (3) than i was about bug (1). because both of them turn into segfaults depending on minor code changes, it is possible that bug (2), which i have so far only been able to reproduce as a segfault, could _also_ manifest as a silent vulnerability.

i would advise that people using concurrency features **should not ship _anything_ compiled with the 5.5 toolchain** , until these issues are fixed and a patch is released.

* * *

(update) it looks like there is yet another issue with task groups and SIMD types with wide alignments. see [this followup](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344/7). i have confirmed this issue affects the 5.5-RELEASE toolchain as well. i was able to reproduce it on both debug and release builds.

1. 

| present in 5.5-RELEASE? | present in debug builds? | present in release builds? |
| --- | --- | --- |
| **yes** | **yes** | **yes** |

reproduction:

```swift
@main
enum Main
{
    static
    func main() async
    {
        await withTaskGroup(of: SIMD4<Int32>.self) 
        { 
            (group:inout TaskGroup) in
            group.addTask 
            {
                return SIMD4<Int32>.init(repeating: 0)
            }
        }
    }
}

```

```nohighlight
$ swiftc --version
Swift version 5.5 (swift-5.5-RELEASE)
Target: x86_64-unknown-linux-gnu
$ swiftc -O -parse-as-library async-stack-corruption-simd.swift 
$ ./async-stack-corruption-simd 
Segmentation fault (core dumped)

```

---

<div class="post-metadata">

**Author:** ![mickeyl](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/mickeyl/32/12258_2.png) [@mickeyl](https://forums.swift.org/u/mickeyl)\
**Post date:** [September 25, 2021, 8:06am UTC](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344/2 "2021-09-25T08:06:45Z")

</div>

Thanks for investigating. These look even more scary than the [crashes due to memory management](https://forums.swift.org/t/concurrency-continuation-memory-management/52332/2) I have seen.

---

<div class="post-metadata">

**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\
**Post date:** [September 25, 2021, 5:21pm UTC](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344/3 "2021-09-25T17:21:15Z")

</div>

after investigating further, it looks like bug #3, or at least a variant of it **does in fact affect the 5.5-RELEASE toolchain.**

a modified example program to reproduce this problem is given below:

```swift
struct Users
{
    enum Access 
    {
        case guest
        case admin(Int)
        case developer(Int, Int, Int, Int)
    }
    
    private 
    actor User 
    {
        init()
        {
        }
        
        func set(permissions:(Int, Access?))
        {
            print(permissions)
        }
    }
    
    private 
    let users:[Int: User] = [0: .init()]
    
    func set(permissions:(Int, Access?)) async 
    {
        print(permissions)
        guard let user:User = self.users[permissions.0]
        else 
        {
            print(" \(permissions.0) ")
            return  
        }
        await user.set(permissions: permissions)
    }
}

@main 
enum Main 
{
    static 
    func main() async
    {
        let coordinator:Users = .init()
        let stream:AsyncStream<Int> = .init 
        {
            for i in 0 ..< 10
            {
                $0.yield(i) 
            }
            $0.finish()
        }

        for await i:Int in stream
        {
            if i != 0 
            {
                continue 
            }
            await coordinator.set(permissions: (i, .guest))
        }
    }
}

```

```nohighlight
$ swiftc --version
Swift version 5.5 (swift-5.5-RELEASE)
Target: x86_64-unknown-linux-gnu
$ swiftc -O -parse-as-library async-stack-corruption-5.5.swift
$ ./async-stack-corruption-5.5 
(0, Optional(main.Users.Access.admin(144)))
(0, Optional(main.Users.Access.admin(144)))

```

moreover, while investigating this bug, i also noticed that i could influence the specific enum cases that the real values are overwritten with based on user input. this means that (alongside [SR-15225](https://bugs.swift.org/browse/SR-15225)) [SR-15240](https://bugs.swift.org/browse/SR-15240) represents a major security vulnerability in Swift 5.5. it is also highly chaotic — removing or reordering any of the `print` statements in this program completely changes the behavior — so it is extremely likely that a minor change in your codebase before a release could silently introduce a vulnerability.

again, i would urge anyone using the 5.5-RELEASE toolchain to either avoid concurrency features, or **assume that all binaries compiled with it are compromised.**

---

<div class="post-metadata">

**Author:** ![Luis](https://avatars.discourse-cdn.com/v4/letter/l/3e96dc/32.png) [@Luis](https://forums.swift.org/u/Luis)\
**Post date:** [September 27, 2021, 8:07pm UTC](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344/4 "2021-09-27T20:07:21Z")

</div>

> [@taylorswift](#):
>
> the enum values received by an actor-isolated method are not the same values that were passed by the caller.

Hi, am experiencing a similar problem and do not know how to fix it. Have you found a workaround?

---

<div class="post-metadata">

**Author:** ![timdecode](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/timdecode/32/16499_2.png) [@timdecode](https://forums.swift.org/u/timdecode)\
**Post date:** [September 27, 2021, 8:46pm UTC](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344/5 "2021-09-27T20:46:25Z")

</div>

I don't know if this is related but I get a crash with simd types and task groups on macOS with XCode 13 release (13A233) and beta 5 (13A5212g) on Intel (i9) but it's fine on Arm. It smells like an alignment issue to me (it works with simd\_int2, for example). I filed a bug in Apple's Feedback app (FB9531735).

The crash is at: `thunk for @escaping @callee_guaranteed @Sendable @async () -> (@unowned SIMD4<Int32>):`

Here's some code:

```nohighlight
import simd

@main
enum CrashApp
{
    static
    func main() async
    {
        await withTaskGroup(of: simd_int4.self) { group in
            for i in 0..<10 {
                group.addTask {
                    return simd_int4(repeating: Int32(i))
                }
            }
         
            for await test in group {
                print( test.x )
            }
        }
    }
}

```

---

<div class="post-metadata">

**Author:** ![mickeyl](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/mickeyl/32/12258_2.png) [@mickeyl](https://forums.swift.org/u/mickeyl)\
**Post date:** [September 28, 2021, 8:45am UTC](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344/6 "2021-09-28T08:45:51Z")

</div>

Indeed, lots of strange things happening w/ 5.5, in particular with concurrency though.

This code here:

```swift
/// A stream-based serial command queue
public actor StreamCommandQueue: NSObject {

    let input: InputStream
    let output: OutputStream
    private var pendingCommands: [StreamCommand] = [] //NOTE: Unused, but dare to remove it and we get a stack corruption!
    private var activeCommand: StreamCommand? {
        didSet {
            logger.debug("active command now \(self.activeCommand)")
        }
    }

```

crashes as soon as I remove the **unused** property `pendingCommands` array with the following backtrace:

```swift
(lldb) bt
* thread #2, queue = 'com.apple.root.user-initiated-qos.cooperative', stop reason = EXC_BAD_ACCESS (code=1, address=0xea5b7c95)
  * frame #0: 0x00000000ea5b7c95
    frame #1: 0x0000000105736aee libswift_Concurrency.dylib`swift::runJobInEstablishedExecutorContext(swift::Job*) + 158
    frame #2: 0x00000001057371ef libswift_Concurrency.dylib`swift_job_runImpl(swift::Job*, swift::ExecutorRef) + 63
    frame #3: 0x000000010851a3a0 libdispatch.dylib`_dispatch_continuation_pop + 93
    frame #4: 0x0000000108519964 libdispatch.dylib`_dispatch_async_redirect_invoke + 778
    frame #5: 0x0000000108529b44 libdispatch.dylib`_dispatch_root_queue_drain + 403
    frame #6: 0x000000010852a5ec libdispatch.dylib`_dispatch_worker_thread2 + 196
    frame #7: 0x00007fff6bfeb417 libsystem_pthread.dylib`_pthread_wqthread + 244
    frame #8: 0x00007fff6bfea42f libsystem_pthread.dylib`start_wqthread + 15

```

---

<div class="post-metadata">

**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\
**Post date:** [September 28, 2021, 7:09pm UTC](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344/7 "2021-09-28T19:09:17Z")

</div>

> [@timdecode](#):
>
> I don't know if this is related but I get a crash with simd types and task groups on macOS with XCode 13 release (13A233) and beta 5 (13A5212g) on Intel (i9) but it's fine on Arm. It smells like an alignment issue to me (it works with simd\_int2, for example). I filed a bug in Apple's Feedback app (FB9531735).

i am able to reproduce on linux, using the builtin `SIMD4<T>` type. the issue also affects the 5.5-RELEASE toolchain. moreover, it occurs even _with a single child task, returning a single constant SIMD value_.

```swift
@main
enum Main
{
    static
    func main() async
    {
        await withTaskGroup(of: SIMD4<Int32>.self) 
        { 
            (group:inout TaskGroup) in
            group.addTask 
            {
                return SIMD4<Int32>.init(repeating: 0)
            }
        }
    }
}

```

```plaintext
$ swiftc --version
Swift version 5.5 (swift-5.5-RELEASE)
Target: x86_64-unknown-linux-gnu
$ swiftc -O -parse-as-library async-stack-corruption-simd.swift 
$ ./async-stack-corruption-simd 
Segmentation fault (core dumped)

```

have you filed a bug on bugs.swift.org? it might help to link it to the other issues here

---

<div class="post-metadata">

**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\
**Post date:** [September 28, 2021, 7:24pm UTC](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344/8 "2021-09-28T19:24:31Z")

</div>

> [@Luis](#):
>
> Hi, am experiencing a similar problem and do not know how to fix it. Have you found a workaround?

not really. i tried wrapping some of these return values in “padding” structs in hopes that the memory offset being corrupted would correspond to padding, but it just made the memory corruption more irregular and harder to identify.

---

<div class="post-metadata">

**Author:** ![Luis](https://avatars.discourse-cdn.com/v4/letter/l/3e96dc/32.png) [@Luis](https://forums.swift.org/u/Luis)\
**Post date:** [September 29, 2021, 8:33pm UTC](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344/9 "2021-09-29T20:33:39Z")

</div>

I have been spending countless hours investigating so many problems that were in truth bugs from the compiler. Why did these problems not get found in testing? Why did Apple published it as a Swift RELEASE? How is Swift a "safe language" if we cannot trust some thing as sensible as a return value?

---

<div class="post-metadata">

**Author:** ![Karl](https://avatars.discourse-cdn.com/v4/letter/k/34f0e0/32.png) [@Karl](https://forums.swift.org/u/Karl)\
**Post date:** [September 29, 2021, 10:45pm UTC](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344/10 "2021-09-29T22:45:19Z")

</div>

You’re right, these are very serious problems. I don’t remember issues of comparable severity in any Swift release, and the fact they weren’t discovered during testing is very troubling. It probably warrants some sort of post-mortem analysis, including a plan to improve on the project’s apparent deficiencies in testing, but that can only happen once the issues are identified and fixed.

I don’t know if that discussion will happen and the results shared with the community, but I hope they will be.

---

<div class="post-metadata">

**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\
**Post date:** [September 29, 2021, 11:01pm UTC](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344/11 "2021-09-29T23:01:53Z")

</div>

> [@Luis](#):
>
> Why did these problems not get found in testing? Why did Apple published it as a Swift RELEASE? How is Swift a "safe language" if we cannot trust some thing as sensible as a return value?

> [@Karl](#):
>
> I don’t remember issues of comparable severity in any Swift release, and the fact they weren’t discovered during testing is very troubling. It probably warrants some sort of post-mortem analysis, including a plan to improve on the project’s apparent deficiencies in testing, but that can only happen once the issues are identified and fixed.

i have been in contact with one of the compiler devs, and they seem to be aware of the issue, and i’ve gotten assurances that this is being worked on. however, even without knowing the exact technical cause of the problem, we need to recognize that _bugs happen_, and the more important structural issue is why we did not have systems in place to prevent bugs like this from making it into official release binaries.

i think we do need to be having discussions about just what level of stability a Swift _release_ should imply, and whether we should be providing some sort of “long-term-support” releases with stronger stability guarantees than the regularly-cycled releases. `async`/`await` in particular tends to be used in real-time safety-critical applications where bugs like these could cause significant real-world harm, and the fact that we don’t even provide “safety-grade” toolchains for people who need these guarantees is a deficiency in the language.

---

<div class="post-metadata">

**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\
**Post date:** [September 29, 2021, 11:46pm UTC](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344/12 "2021-09-29T23:46:04Z")

</div>

update: i’ve kicked off discussions for “long-term releases” here:

> [@We need long-term-support” (“LTS”) releases](https://forums.swift.org/t/we-need-long-term-support-lts-releases/52462):
>
> overview for those who don’t follow the [Development](https://forums.swift.org/c/development) topic, @mickeyl, @timdecode, and i have recently [uncovered an alarming number of highly dangerous stack corruption bugs](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344) in the Swift 5.5 release toolchain. setting aside the technical aspects of the stack corruption issues in Swift 5.5, which are detailed in the [corresponding thread](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344), i would like to kickoff discussions on whether it would be valuable for us to adopt some form of the concept of a [“Long-Term Support” (LTS) release](https://en.wikipedia.org/wiki/Long-term_support) in our release…

---

<div class="post-metadata">

**Author:** ![Luis](https://avatars.discourse-cdn.com/v4/letter/l/3e96dc/32.png) [@Luis](https://forums.swift.org/u/Luis)\
**Post date:** [September 30, 2021, 8:02am UTC](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344/13 "2021-09-30T08:02:35Z")

</div>

> [@taylorswift](#):
>
> i think we do need to be having discussions about just what level of stability a Swift _release_ should imply, and whether we should be providing some sort of “long-term-support” releases with stronger stability guarantees than the regularly-cycled releases.

I am sorry, but I do not believe that this would solve the real cause of the big problem, that which is Apple decided to release the new compiler without I think testing it at all. The types of problems I am finding are the type that make that me think whoever gave the OK for this compiler release would also give the same OK for your "long term support release"

---

<div class="post-metadata">

**Author:** ![Panajev](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/panajev/32/1227_2.png) [@Panajev](https://forums.swift.org/u/Panajev)\
**Post date:** [September 30, 2021, 8:03am UTC](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344/14 "2021-09-30T08:03:32Z")

</div>

I think that tying Swift runtime to the OS releases is a risk unless the language stops evolving with large jumps in features that require a runtime update. Kotlin and Jetpack Compose Evolution on Android benefit from being decoupled from Android OS releases.

---

<div class="post-metadata">

**Author:** ![gwendal.roue](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/gwendal.roue/32/13992_2.png) [@gwendal.roue](https://forums.swift.org/u/gwendal.roue)\
**Post date:** [September 30, 2021, 9:01am UTC](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344/15 "2021-09-30T09:01:52Z")

</div>

> [@Panajev](#):
>
> I think that tying Swift runtime to the OS releases is a risk unless the language stops evolving with large jumps in features that require a runtime update. Kotlin and Jetpack Compose Evolution on Android benefit from being decoupled from Android OS releases.

The compiler does not ship with the OS, unlike the Swift runtime and stdlibs. This ship has sailed. All the hard work around ABI stability on Apple platforms had this unique goal in mind: ship the stdlib and the runtime in the OS, so that apps do not have to bundle it.

I actually don't know if bugs spotted by @taylorswift and friends live only in the compiler, or in the runtime, or in both.

If they only live in the compiler, then only a future toolchain, or a Xcode update, will fix those bugs.

If they live partially in the runtime that ships with the OS, then, regardless of compiler releases, some devices are irremediably subject to bugs, unless the application code contains workarounds for impacted system versions.

---

<div class="post-metadata">

**Author:** ![Panajev](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/panajev/32/1227_2.png) [@Panajev](https://forums.swift.org/u/Panajev)\
**Post date:** [September 30, 2021, 11:10am UTC](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344/16 "2021-09-30T11:10:04Z")

</div>

I am aware that the compiler does not ship with the apps and only the runtime and stdlibs do and hopefully as you said the issues has workarounds that do not require iOS 15.1 or 15.0.1 as minimum requirement but only code changes and compiler changes.

I understand third party apps not having to bundle stdlib and Swift runtime was one of the goals behind this decision and I understand the implications you explained afterwards (fingers crossed for the backdeployment to iOS 15.0 being possible thanks to @Douglas_Gregor work :)), but it is orthogonal to what I was saying and it a balancing act of pros and cons. This is one of the cons. For many third party apps being able to bundle Swift runtime and standard libraries as an option would help: app binary size is not the #1 concern / most pressing concern many devs have (dwarfed by content/data size in many case) and also not more important than app correctness/safety.

There are cons to Kotlin being JVM based on Android, but there are pros (mostly independent from Android Studio updates and Android OS updates), the same go for other components like Compose or Webview that are packed with the apps or updated by Google Play Services and backdeploy to Android 5+.

---

<div class="post-metadata">

**Author:** ![Jean-Daniel](https://avatars.discourse-cdn.com/v4/letter/j/977dab/32.png) [@Jean-Daniel](https://forums.swift.org/u/Jean-Daniel)\
**Post date:** [September 30, 2021, 1:25pm UTC](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344/17 "2021-09-30T13:25:22Z")

</div>

> [@Panajev](#):
>
> I understand third party apps not having to bundle stdlib and Swift runtime was one of the goals behind this decision

This is not the main one.  
Without ABI stability, Apple would not be able to expose Swift API from system frameworks.  
If you want to release a "stand-alone" app, you should not only embed runtime and stdlib, but also all Swift frameworks that your app is using.

Most android apps already do that (embedding multi megabytes of system libraries to workaround fragmentation issue), the drawback being that you can't fix bug system wide. Every single app has to be recompile and updated when there is a bug in one support library.

If Kotlin is independent of Android Studio and Android, this is because the JVM guarantee ABI stability, but it also means Kotlin can't use advanced code optimisation technics, as it is limited by what the JVM support.

In this regards, Swift `async/await` is far more advanced than Kotlin coroutines.

---

<div class="post-metadata">

**Author:** ![Panajev](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/panajev/32/1227_2.png) [@Panajev](https://forums.swift.org/u/Panajev)\
**Post date:** [September 30, 2021, 1:32pm UTC](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344/18 "2021-09-30T13:32:57Z")

</div>

I appreciate it is an option with costs involved, but as an option it would allow an easier path out of critica bugs such as this one and would allow the language and frameworks to iterate faster as they would get real world use sooner. I see these benefits as being more important than binary size and performance difference that while not being trivial would you say it is that massive?

Not disputing it has pros, but it has its cons

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [September 30, 2021, 1:41pm UTC](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344/19 "2021-09-30T13:41:25Z")

</div>

Every serious bug that arises cannot devolve into a discussion about Apple’s decision regarding Swift-in-the-OS, which has never been the community’s call to make in the first place. Let’s keep this topic focused on the problem at hand.

---

<div class="post-metadata">

**Author:** ![Panajev](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/panajev/32/1227_2.png) [@Panajev](https://forums.swift.org/u/Panajev)\
**Post date:** [September 30, 2021, 1:44pm UTC](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344/20 "2021-09-30T13:44:49Z")

</div>

Ok, will cut the derailment here sorry for that. I think that regardless of what is supposed to be the call of the community or not, you revise decisions based on new evidence if not it becomes a religious matter.

[Next page](https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344.md?page=2)