Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Intermittent crash when cancelling an authentication session #902

Open
6 tasks done
bmarkowitz opened this issue Feb 13, 2025 · 7 comments · May be fixed by #904
Open
6 tasks done

Intermittent crash when cancelling an authentication session #902

bmarkowitz opened this issue Feb 13, 2025 · 7 comments · May be fixed by #904
Labels
bug This points to a verified bug in the code

Comments

@bmarkowitz
Copy link

bmarkowitz commented Feb 13, 2025 •
edited
Loading

Checklist

Description

We've been seeing a sizable number of crashes when auth sessions are cancelled, specifically when the userCancelled error fires.

Reproduction

While we don't believe the following steps are the same ones taken by users, we do believe this is a reliable way of reproducing the issue that users are non-deterministically running into after opening the app following some time in the background.

We've been able to reproduce the crash with the same steps using our own app, the sample app, and other apps that use Auth0, like ChatGPT.

  1. Open the app. Ensure you're in a logged-out state before proceeding to step 2.
  2. Enter the login flow.
  3. When prompted with the system sign in alert, tap Continue. You should now be viewing an Auth0 login flow within a SafariViewController.
  4. Put the app into the background. Don't force close it.
  5. Go into Settings and go into Safari settings.
  6. Tap Clear History and Website Data
  7. Tap Clear History and Data in the alert that appears. In newer versions of iOS, this step and the next one are combined into a single sheet.
  8. Tap Keep Tabs in the alert that appears.
  9. Go back to the app. The SafariViewController should refresh and you should get the same system sign in prompt from step 3.
  10. Tap Cancel.
  11. App crashes.

Additional context

Stack trace:

Thread 0:
0 libobjc.A.dylib 0x286c objc_release_x8 + 12
1 libsystem_blocks.dylib 0x285c HelperBase<ExtendedInline>::disposeCapture<(HelperBase<ExtendedInline>::BlockCaptureKind)3>(unsigned int, unsigned char*) + 64
2 libsystem_blocks.dylib 0x256c HelperBase<GenericInline>::destroyBlock(Block_layout*, bool, unsigned char*) + 156
3 libsystem_blocks.dylib 0x202c _call_dispose_helpers_excp + 68
4 libsystem_blocks.dylib 0x1fc8 _Block_release + 252
5 libsystem_blocks.dylib 0x1e8c HelperBase<ExtendedInline>::disposeCapture<(HelperBase<ExtendedInline>::BlockCaptureKind)4>(unsigned int, unsigned char*) + 64
6 libsystem_blocks.dylib 0x2580 HelperBase<GenericInline>::destroyBlock(Block_layout*, bool, unsigned char*) + 176
7 libsystem_blocks.dylib 0x202c _call_dispose_helpers_excp + 68
8 libsystem_blocks.dylib 0x1fc8 _Block_release + 252
9 libsystem_blocks.dylib 0x1e8c HelperBase<ExtendedInline>::disposeCapture<(HelperBase<ExtendedInline>::BlockCaptureKind)4>(unsigned int, unsigned char*) + 64
10 libsystem_blocks.dylib 0x2580 HelperBase<GenericInline>::destroyBlock(Block_layout*, bool, unsigned char*) + 176
11 libsystem_blocks.dylib 0x202c _call_dispose_helpers_excp + 68
12 libsystem_blocks.dylib 0x1fc8 _Block_release + 252
13 libsystem_blocks.dylib 0x1e8c HelperBase<ExtendedInline>::disposeCapture<(HelperBase<ExtendedInline>::BlockCaptureKind)4>(unsigned int, unsigned char*) + 64
14 libsystem_blocks.dylib 0x2580 HelperBase<GenericInline>::destroyBlock(Block_layout*, bool, unsigned char*) + 176
15 libsystem_blocks.dylib 0x202c _call_dispose_helpers_excp + 68
16 libsystem_blocks.dylib 0x1fc8 _Block_release + 252
17 CoreFoundation 0x94b0 __RELEASE_OBJECTS_IN_THE_ARRAY__ + 112
18 CoreFoundation 0x93ec -[__NSArrayM dealloc] + 144
19 UIKitCore 0x2e33d0 -[_UIViewControllerTransitionContext _runAlongsideCompletions] + 140
20 UIKitCore 0x2e319c -[_UIViewControllerTransitionContext completeTransition:] + 200
21 UIKitCore 0x7bfac __UIVIEW_IS_EXECUTING_ANIMATION_COMPLETION_BLOCK__ + 32
22 UIKitCore 0x12ab84 -[UIViewAnimationBlockDelegate _sendDeferredCompletion:] + 100
23 libdispatch.dylib 0x236c _dispatch_call_block_and_release + 28
24 libdispatch.dylib 0x40cc _dispatch_client_callout + 16
25 libdispatch.dylib 0x129dc _dispatch_main_queue_drain + 976
26 libdispatch.dylib 0x125f8 _dispatch_main_queue_callback_4CF + 40
27 CoreFoundation 0x56200 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
28 CoreFoundation 0x5343c __CFRunLoopRun + 1992
29 CoreFoundation 0x5282c CFRunLoopRunSpecific + 584
30 GraphicsServices 0x11c0 GSEventRunModal + 160
31 UIKitCore 0x3d2eac -[UIApplication _run] + 812
32 UIKitCore 0x4815b0 UIApplicationMain + 336
33 Ibotta 0x80b8 main + 184
34  0x1b6d9aec8 0x0 + 7362686664

Auth0.swift version

2.10.0

Platform

iOS

Platform version(s)

15.0+

Xcode version

16.2

Package manager

Swift Package Manager
@bmarkowitz bmarkowitz added the bug This points to a verified bug in the code label Feb 13, 2025
@bmarkowitz
Copy link
Author

This is potentially related/similar to the issue reported here: #343

@bmarkowitz
Copy link
Author

Doing some digging, commenting out storage.clear() on line 202 of Auth0WebAuth seems to "fix" it, although attempting to start another transaction afterwards fails with an error than a transaction is already in progress.

So, I wonder if there's something that's attempting to access the stored AuthTransaction after it's already been cleared from storage.

@bmarkowitz
Copy link
Author

Potentially related:

http://ww.openradar.appspot.com/FB12132525

Note: This crash can be mitigated by intentionally retaining the authentication session until after the dismiss animation is complete — but if all references are removed then the user will encounter the crash.

@Widcket
Copy link
Contributor

Widcket commented Feb 21, 2025 •
edited
Loading

Hi @bmarkowitz, thanks for raising this.

I wonder if the crash experienced by following the reproduction steps is actually related to the SFSafariViewController managed by ASWebAuthenticationSession reloading after clearing the cookies.

Do the stack traces you get from your users' crashes match the stack trace from the reproduction steps?

@bmarkowitz
Copy link
Author

bmarkowitz commented Feb 21, 2025 •
edited
Loading

Hey @Widcket - it's hard to tell honestly. The stack traces we're seeing aren't capturing that explicitly, but we've implemented some additional logging around the flow itself. We're seeing that a cancel action is being initiated (userCancelled) immediately prior to the crash, which we think is tied to the "<app>" Wants to Use "<app>.com" to Sign In prompt, as well as the Cancel button the Safari view controller.

The crash is reproducible with the steps given, but we've also seen it happen in normal usage (without clearing cache/cookies). The Safari view controller will sometimes refresh on its own after bringing the app back into the foreground.

This obviously is not an ideal solution, but wrapping the storage.clear() call in Auth0WebAuth with a very short DispatchQueue.main.asyncAfter seems to "fix" it 😅

@Widcket
Copy link
Contributor

Widcket commented Feb 21, 2025

From what I can see this is a double-release problem deep inside ASWebAuthenticationSession.

Image Image

I'll investigate what can be done to mitigate this problem from the SDK side.

@bmarkowitz
Copy link
Author

Awesome, thank you so much!

@Widcket Widcket linked a pull request Feb 25, 2025 that will close this issue
Open
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug This points to a verified bug in the code
Projects
None yet
Milestone
No milestone
2 participants
@Widcket @bmarkowitz