Перенаправление трассировки стека после std :: terminate в приложении iOS Objective C ++ для Crashlytics

У меня есть приложение для iOS, которое использует Objective C ++ с некоторыми внешними библиотеками C ++, приложение использует Crashlytics для отслеживания возможных сбоев пользователей.

Crashlytics с радостью обрабатывает все исключения, происходящие из земли Objective C, что в прошлом мне очень помогало отслеживать проблемы, я хотел бы получать такие же журналы аварий с конца C ++, когда что-нибудь генерируется.

К сожалению, когда вызывается std :: исключение, все, что я получаю в Crashlytics, это общая трассировка стека, которая не включает в себя источник, это не помогает исправить эти проблемы и не помогает факту, что любое исключение std входит в то же самое универсальный накопленный тип «сбой».

Могу ли я перехватить эти исключения и как-то перенаправить их, чтобы они появлялись рядом с исходными сбоями Objective C?

Я пытаюсь сделать что-то в этом роде, но я не могу заставить его работать, хотя Crashlytics остается в том же рабочем состоянии, я что-то упускаю?

https://stackoverflow.com/a/36733626/5199634

Другое возможное решение, которое я рассматриваю, — перехват исключений C ++ и их регистрация с использованием самого Crashlytics в качестве ошибок, а затем повторное выбрасывание их из оболочки.

https://docs.fabric.io/apple/crashlytics/logged-errors.html

Пример трассировки стека после необработанного исключения C ++:

Crashed: com.twitter.crashlytics.ios.exception
0  MyApp                          0x100d9baac CLSProcessRecordAllThreads + 4312709804
1  MyApp                          0x100d9baac CLSProcessRecordAllThreads + 4312709804
2  MyApp                          0x100d9b968 CLSProcessRecordAllThreads + 4312709480
3  MyApp                          0x100d8b6b8 CLSHandler + 4312643256
4  MyApp                          0x100d99ac4 __CLSExceptionRecord_block_invoke + 4312701636
5  libdispatch.dylib              0x182556a14 _dispatch_client_callout + 16
6  libdispatch.dylib              0x18255f618 _dispatch_queue_barrier_sync_invoke_and_complete + 56
7  MyApp                          0x100d99558 CLSExceptionRecord + 4312700248
8  MyApp                          0x100d99068 CLSTerminateHandler() + 4312698984
9  libc++abi.dylib                0x181e0f54c std::__terminate(void (*)()) + 16
10 libc++abi.dylib                0x181e0f5b8 std::terminate() + 60
11 libobjc.A.dylib                0x181e2076c _destroyAltHandlerList + 10
12 libdispatch.dylib              0x182556a28 _dispatch_client_callout + 36
13 libdispatch.dylib              0x18255e200 _dispatch_block_invoke_direct$VARIANT$mp + 288
14 FrontBoardServices             0x1852d27f8 __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 36
15 FrontBoardServices             0x1852d249c -[FBSSerialQueue _performNext] + 404
16 FrontBoardServices             0x1852d2a38 -[FBSSerialQueue _performNextFromRunLoopSource] + 56
17 CoreFoundation                 0x182b8297c __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24
18 CoreFoundation                 0x182b828fc __CFRunLoopDoSource0 + 88
19 CoreFoundation                 0x182b82184 __CFRunLoopDoSources0 + 204
20 CoreFoundation                 0x182b7fd5c __CFRunLoopRun + 1048
21 CoreFoundation                 0x182a9fe58 CFRunLoopRunSpecific + 436
22 GraphicsServices               0x18494cf84 GSEventRunModal + 100
23 UIKit                          0x18c11f67c UIApplicationMain + 236
24 MyApp                          0x100cec768 main (main.m:14)
25 libdyld.dylib                  0x1825bc56c start + 4