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.

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

iOS Kotlin Multiplatform hang after crash when using DatadogCrashReporting as a result of PLCrashReporter #1714

Closed
alexfanatics opened this issue Mar 8, 2024 · 1 comment
Labels
bug Something isn't working

Comments

@alexfanatics
Copy link
Contributor

Describe the bug

We use KMM within our iOS app. There is currently an issue with PLCrashReporter where the main thread locks up instead of crashing when there is an uncaught exception or fatal error thrown from Swift or Kotlin.

This results in even non KM crashes preventing the app from exiting properly, and instead just locking the UI until there is an overflow of some kind that actually crashes the application.

The issue is described here: microsoft/plcrashreporter#293

Because DatadogCrashReporting uses PLCrashReporter, most Datadog users who use both crash reporting & KMM will be impacted by this.

Are you folks aware of this? Has anyone else had this issue?

Reproduction steps

I've put together a demo application which can reproduce this issue. https://github.com/alexfanatics/PLCrashReporterHangDemo

  1. Clone the repo
  2. you may need to configure your local env to support java/gradle in order to build the KM part of the project
  3. build and run the project from xcode
  4. detatch the debugger
  5. re-open app
  6. crash the app via one of the buttons
  7. try to scroll around. the main thread is pinned and the app wont crash.
  8. minimize the app a few times, eventually it will crash and you will see a crash report with the call stack below.

SDK logs

Crash call stack: 
Triggered by Thread:  0

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   iosApp                        	       0x1004e43e0 plcrash::PL_::async::dwarf_cfa_state<unsigned long long, long long>::remove_register(unsigned int) + 144 (PLCrashAsyncDwarfCFAState.cpp:234)
1   iosApp                        	       0x1004e1bf0 plcrash::PL_::async::dwarf_cfa_state<unsigned long long, long long>::eval_program(plcrash_async_mobject*, unsigned long long, unsigned long long, plcrash::PL_::async::plcrash_async_dwarf_cie_info*, plcrash::PL_::async::gnu_ehptr_reader<unsigned long long>*, plcrash_async_byteorder const*, unsigned long, long, unsigned long) + 2840
2   iosApp                        	       0x1004e48fc plframe_error_t plframe_cursor_read_dwarf_unwind_int<unsigned long long, long long>(unsigned int, unsigned long long, plcrash_async_macho*, plframe_stackframe const*, plframe_stackframe const*, plframe_stackframe*) + 128 (PLCrashFrameDWARFUnwind.cpp:171) [inlined]
3   iosApp                        	       0x1004e48fc plframe_cursor_read_dwarf_unwind + 788 (PLCrashFrameDWARFUnwind.cpp:250)
4   iosApp                        	       0x1004c9f90 plframe_cursor_next_with_readers + 108 (PLCrashFrameWalker.c:151)
5   iosApp                        	       0x1004ca070 plframe_cursor_next + 64 (PLCrashFrameWalker.c:199)
6   iosApp                        	       0x1004cb46c plcrash_writer_write_thread + 600 (PLCrashLogWriter.m:986)
7   iosApp                        	       0x1004cac98 plcrash_log_writer_write + 684 (PLCrashLogWriter.m:1367)
8   iosApp                        	       0x1004ce238 plcrash_write_report + 128 (PLCrashReporter.m:165)
9   iosApp                        	       0x1004cd004 signal_handler_callback + 144 (PLCrashReporter.m:232)
10  iosApp                        	       0x1004c9440 internal_callback_iterator(int, __siginfo*, __darwin_ucontext*, void*) + 108
11  iosApp                        	       0x1004c93b4 plcrash_signal_handler + 24 (PLCrashSignalHandler.mm:201)
12  libsystem_platform.dylib      	       0x10084b7e0 _sigtramp + 52
13  libswiftCore.dylib            	       0x192fcb414 _assertionFailure(_:_:file:line:flags:) + 552
14  iosApp                        	       0x1004c6cd8 closure #1 in ContentView.body.getter + 112 (ContentView.swift:10)

Expected behavior

The app should crash immediately and allow you to open the app and upload your specific crash report.

Affected SDK versions

  • DatadogCrashReporting (2.7.1): - DatadogInternal (= 2.7.1) - PLCrashReporter (~> 1.11.1) - DatadogInternal (2.7.1) - PLCrashReporter (1.11.1)

Latest working SDK version

This is present in all SDK versions as all versions of PLCrashReporter have this issue

Did you confirm if the latest SDK version fixes the bug?

Yes

Integration Methods

Cocoapods

Xcode Version

15.3

Swift Version

swift-driver version: 1.90.11.1 Apple Swift version 5.10 (swiftlang-5.10.0.13 clang-1500.3.9.4)

MacOS Version

Mac OS 14.4 23E214

Deployment Target

17.4

Device Information

No response

Other relevant information

No response

@alexfanatics alexfanatics added the bug Something isn't working label Mar 8, 2024
@maxep
Copy link
Member

maxep commented Mar 11, 2024

Hey @alexfanatics! Thank you for the detailed report and for using our SDK.

I'm able to replicate the issue using your demo application, thank you for sharing it. If I unlink the shared framework (KMM build), the app crashes as expected so it's definitely a compatibility issue between the KMM framework binary and PLCrashReporter.

Sadly, we do not support KMM at this point so we cannot prioritise further investigation. This crash seems to originate from PLCrashReporter, we can hope for a fix on their side.

I'm closing this ticket since the problem is outside the scope of our SDK, but feel free to add any additional findings. We will keep a eye on PLCrashReporter updates.

@maxep maxep closed this as completed Mar 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants