Обозначение отчета о сбое iOS без dsym — адрес символа вне адресов, видимых в двоичном файле

Я пытаюсь символизировать отчет о сбое iOS, для которого у меня нет файла dsym. Я знаю, что не смогу получить хорошую символику file_name: номер строки, но выяснить, где в разделе сборки кода происходит сбой, будет достаточно.

Для начала вот трассировка стека потерянного потока:

Thread 3 name:  Dispatch queue: com.unity3d.WebOperationQueue :: NSOperation 0x1483250e0 (QOS: USER_INTERACTIVE)
Thread 3 Crashed:
0   myapp                       0x0000000100ec4738 0x100080000 + 14960440
1   myapp                       0x000000010120e0fc 0x100080000 + 18407676
2   myapp                       0x00000001011d7e00 0x100080000 + 18185728
3   myapp                       0x0000000100085cfc 0x100080000 + 23804
4   CFNetwork                   0x0000000185027780 __65-[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:]_block_invoke + 80
...

У меня есть расшифрованный бинарный файл и я проверил UUID из отчета о сбое и бинарные совпадения. Чтобы вручную обозначить адрес стека, я делаю это

atos -arch arm64 -o myapp -l 0x100080000 0x0000000100ec4738

и я получаю вывод из вышеуказанной команды как

0x0000000100e44738 (in myapp) + 544

Это частично ожидается, потому что у меня нет файла dsym.

Обратите внимание, что 0x0000000100e44738 также можно получить, если мы рассчитаем

symbol address as = (slide + stack - load address)

слайд 0x0000000100000000 (найдено как vmaddr из otool -arch arm64 -l myapp | grep -B 3 -A 8 -m 2 "__TEXT" )

так 0x0000000100000000 + 0x0000000100ec4738 - 0x100080000 = 0x100e44738 так же, как и выше адрес, который вернулся atos.

Теперь проблема в том, что я не нахожу 0x100e44738 адрес символа в адресах из раздела ТЕКСТ в двоичном файле, который я получаю с помощью приведенной ниже команды otool

otool -tvV myapp

Начало вышеуказанной команды выглядит следующим образом.

myapp:
(__TEXT,__text) section
__ZNK5physx14NpSceneQueries10multiQueryINS_12PxRaycastHitEEEbRKNS_15MultiQueryInputERNS_13PxHitCallbackIT_EENS_7PxFlagsINS_9PxHitFlag4EnumEtEEPKNS_12PxQueryCacheERKNS_17PxQueryFilterDataEPNS_21PxQueryFilterCallbackEPNS_20BatchQueryFilterDataE:
0000000101262f40    stp x28, x27, [sp, #-96]!
0000000101262f44    stp x26, x25, [sp, #16]
0000000101262f48    stp x24, x23, [sp, #32]
0000000101262f4c    stp x22, x21, [sp, #48]
0000000101262f50    stp x20, x19, [sp, #64]
0000000101262f54    stp x29, x30, [sp, #80]
...

Мы можем ясно увидеть начальный адрес из otool -tvV (0x101262f40) больше чем symbol address (0x100e44738), Поэтому я не могу найти то, что я пропустил или как идти отсюда.

Эта трассировка стека предназначена для исключения SIGSEGV, и я не уверен, что это что-то меняет. Я попробовал те же самые шаги ручной символизации в другом примере приложения с исключением SIGABRT, и я вижу, что он смог указать на сбой на точную линию в сборке.

Любая помощь или указатели приветствуются.