What Does "Arg = Exploded" Mean in Swift Crash Log

What's Dead & Exploded in Swift's exception stack?

What does it mean?

The Swift compiler marks function arguments for a number of reasons, mostly related to internal optimizations. For your question, we'll focus on the mangler, as that's what's contributing to your pretty stack trace, and the Node Printer. As of the time of this post, the function specialization mangler has 6 marks it can apply to an argument:

  • Dead

    The argument is unused in the function body and can be removed in a dead argument elimination pass.

  • Closure

    The argument is a closure and may require further mangling/demangling.

  • Constant

    The argument is a constant.

  • Owned to Guaranteed

    A caller-owned argument transfers ownership to the callee. The argument thus has a strong reference associated with it [the caller] and is guaranteed to live through the call, so the compiler allows the caller to elide the transfer and instead aggregate retains itself.

  • SROA

    A Scalar Replacement of Aggregates pass should optimize this argument.

  • In Out To Value

    The parameter was marked inout but the callee doesn't actually mutate it.

The AST Node Printer adds one more mark

  • Exploded

    The value comes with an explosion schema that has been realized when the call was made.

For all intents and purposes we only care about Dead, Owned to Guaranteed, and Exploded.

The only one that may still seem mystifying is Exploded. An Explosion is an optimization construct the Swift compiler uses to determine a strategy to unpack values from small structs and enums into registers. Thus, when the Node Printer says a value is Exploded, what it means it has already unpacked the value into registers before the call.

does it matter for debugging purposes?

Nope.

Function signature specialization crash in swift

You need to look at what the actual exception is. The most common is "unexpectedly found nil while unwrapping an Optional Value" which would suggest that you're passing a String! to this method that was really nil. But you need to start by looking at the exception message, not just the crash stack.



Related Topics



Leave a reply



Submit