SwiftUI frames show OUTLINED_FUNCTION

[philipphofmann]

Platform

iOS

Version

8.4.0

Steps to Reproduce

One of our customers reported this problem. I don't know how to reproduce this.

Expected Result

The event should display meaningful function names for SwiftUI frames.

Actual Result

The stacktrace shows OUTLINED_FUNCTION

[philipphofmann]

This might be related to apple/swift#65059.

[brustolin]

AFAIK OUTLINED_FUNCTION is Swift blocks, this "functions" have no name.

[filip-doordash]

The funny thing is, in Xcode Organizer, under crashes, I can see the real function names for these addresses. For example, what Sentry reports as:

0   SwiftUI                         0x352ceb854         OUTLINED_FUNCTION_34
1   SwiftUI                         0x352453248         [inlined] OUTLINED_FUNCTION_374
2   SwiftUI                         0x352453248         OUTLINED_FUNCTION_374
3   SwiftUI                         0x3525741a8         OUTLINED_FUNCTION_1
4   SwiftUI                         0x352763090         objectdestroy.3901Tm
5   SwiftUI                         0x3522eca10         OUTLINED_FUNCTION_674
6   SwiftUI                         0x35362f358         OUTLINED_FUNCTION_26
7   SwiftUI                         0x353731d1c         OUTLINED_FUNCTION_5
8   SwiftUI                         0x35226220c         OUTLINED_FUNCTION_29
9   SwiftUI                         0x35225ff7c         OUTLINED_FUNCTION_157
10  SwiftUI                         0x352301f44         OUTLINED_FUNCTION_450
11  SwiftUI                         0x3529f77f8         OUTLINED_FUNCTION_2

is actually equivalent to this stack in the Xcode organizer:

0   SwiftUI                       	0x00000001a2c1f854 specialized PreferenceNode.find<A>(key:) + 16 (PreferenceList.swift:146)
1   SwiftUI                       	0x00000001a238724c specialized GraphHost.preferenceValue<A>(_:) + 200 (PreferenceList.swift:15)
2   SwiftUI                       	0x00000001a24a81ac $s7SwiftUI19UIHostingControllerC12promoteTitle2inyAA17EnvironmentValuesV_tFAA31ContentNavigationV3Strategy_iOSV18ColumnModifiedViewV_TB5Tm + 220
3   SwiftUI                       	0x00000001a2697094 partial apply for specialized closure #1 in UINavigationController.updateRootHost<A>(root:environment:transaction:) + 40
4   SwiftUI                       	0x00000001a2220a14 CustomGraphMutation.apply() + 28 (GraphHost.swift:789)
5   SwiftUI                       	0x00000001a356335c closure #1 in AsyncTransaction.apply() + 148 (GraphHost.swift:825)
6   SwiftUI                       	0x00000001a3665d20 specialized closure #1 in withTransaction<A>(_:_:) + 80 (Transaction.swift:115)
7   SwiftUI                       	0x00000001a2196210 GraphHost.flushTransactions() + 456 (<compiler-generated>:0)
8   SwiftUI                       	0x00000001a2193f80 closure #1 in ViewRendererHost.render(interval:updateDisplayList:) + 480 (ViewRendererHost.swift:198)
9   SwiftUI                       	0x00000001a2235f48 ViewRendererHost.render(interval:updateDisplayList:) + 448 (ViewRendererHost.swift:0)
10  SwiftUI                       	0x00000001a292b7fc $s7SwiftUI14_UIHostingViewC22requestImmediateUpdateyyFyyScMYccfU_ + 72 (_UIHostingView.swift:495)
11  SwiftUI                       	0x00000001a21cab3c thunk for @escaping @callee_guaranteed () -> () + 32 (<compiler-generated>:0)

Based on this, I'm guessing Sentry searches for the function name closest to the address, whereas Apple has internal dSYMs for private frameworks. That said, I wonder if we could either:

A. Reach out to Apple, and express the need for them to share the internal SwiftUI dSYMs

B. Build our own representation of the private SwiftUI stacks. For example, if we wrote a script that took in a symbolized stack as input from Xcode Organizer and exported the mappings to a dSYM file. As long as we ensure that the iOS version & device remains the same, I think this should be fine. We could then use this to properly symbolize SwiftUI stacks

[brustolin]

whereas Apple has internal dSYMs for private frameworks

I don't think so. This are closures created in the project, they are not part of the private framework.

[brustolin]

@filip-doordash, what do you mean with stack in the Xcode organizer?
Is this a crash report from appconnect?

[filip-doordash]

I don't think so. This are closures created in the project, they are not part of the private framework.

well, you only knew that they were closures thanks to the properly symbolized stack trace that I attached -- which aren't symbols publicly known :)

Is this a crash report from appconnect?

Negative. Open Xcode and go to -> Window -> Organizer or (CMD+OPTION+SHIFT+O), and you'll see Reports under its tab. Next, click on "crashes". I'm saying that these reports are symbolized with more information than Sentry.

I also understand that Sentry downloads the IPSW image and extracts symbols from the dyld_shared_cache. But I don't think that is guaranteed to have the same symbols as Apple would.

[brustolin]

well, you only knew that they were closures thanks to the properly symbolized stack trace that I attached -- which aren't symbols publicly known :)

I know that they are closures because OUTLINED_FUNCTION is the default name for it in SwiftUI.

Negative. Open Xcode and go to -> Window -> Organizer or (CMD+OPTION+SHIFT+O), and you'll see Reports under its tab. Next, click on "crashes". I'm saying that these reports are symbolized with more information than Sentry.

This is a crash report from AppConnect. Which make me believe that is possible to generate a user friendly description with the project dSYMs alone.

[github-actions]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[brustolin]

We still need to investigate whether is possible to generate an user friendly description.

[brustolin]

Ok, so I got a thing wrong here, this "OUTLINED_FUNCTION" frames are from SwiftUI itself and not the app. Our symbolication process do have a proper description for closures when the symbols are uploaded.

I don't think we need to worry too much about this, since this frames are no related to the app code and we have no access to its symbols.

[philipphofmann]

Emerge Tools recently published a blog post on how they achieved symbolicating SwiftUI memory addresses. We could try a similar approach and give them credits in our code.