Kscrash: KSThread вызывает сбой при получении имени очереди

Это мой крах №1, может кто-нибудь взглянуть на эту проблему? или мне сделать свою ветку этого проекта?

Последние несколько недель я был слишком занят работой (новая работа). Если кто-то делает пиар, я обычно быстро их сливаю!

Хорошо спасибо!

@ferrous777 повезло? Я также вижу этот сбой.

Я не могу понять, как воспроизвести эту проблему, но похоже, что dispatch_queue_ptr , которую мы получаем от thread_identifier_info_t.dispatch_qaddr , указывает на поддельное местоположение. Я только что отправил PR, который добавляет KSThread_Test обратно (https://github.com/kstenerud/KSCrash/pull/221), но я не мог понять, как добавить тест, который даст нам это фиктивное поведение указателя.

e8977a426ab3ef83939a1929c9c4743ae314bcd1 должен решить эту проблему. Он не проверял допустимый указатель перед разыменованием. Это также помечено как 1.15.5, и я нажимаю на кокоаподы.

@kstenerud Привет, чувак, я проверил твой коммит
но для этой строки кода:
dispatch_queue_t* dispatch_queue_ptr = (dispatch_queue_t*)idInfo->dispatch_qaddr;

Ошибок при сборке не было?

Получил ту же ошибку/сбой, версия:

- KSCrash/Core (1.15.18):
    - KSCrash/Reporting/Filters/Basic
  - KSCrash/Recording (1.15.18):
    - KSCrash/Recording/Tools (= 1.15.18)
  - KSCrash/Recording/Tools (1.15.18)
  - KSCrash/Reporting/Filters/Base (1.15.18):
    - KSCrash/Recording
  - KSCrash/Reporting/Filters/Basic (1.15.18):
    - KSCrash/Recording
    - KSCrash/Reporting/Filters/Base

журналы:

[0  KSCrash                        0x102e22754 ksthread_getQueueName + 132
1  KSCrash                        0x102e22738 ksthread_getQueueName + 104
2  KSCrash                        0x102e0a4c0 monitorCachedData + 288
3  libsystem_pthread.dylib        0x185bac2b4 _pthread_body + 308
4  libsystem_pthread.dylib        0x185bac180 _pthread_body + 310
5  libsystem_pthread.dylib        0x185baab74 thread_start + 4]

Я только что видел такой же сбой в KSCrash 1.15.18:

Thread 2 Crashed:
0   KSCrash                         0x0000000103052280 ksthread_getQueueName + 320128 (KSThread.c:87)
1   KSCrash                         0x0000000103052268 ksthread_getQueueName + 320104 (KSThread.c:80)
2   KSCrash                         0x000000010302b050 monitorCachedData + 159824 (KSCrashCachedData.c:139)
3   libsystem_pthread.dylib         0x0000000182d6c31c 0x182d6a000 + 8988 ( + 308)
4   libsystem_pthread.dylib         0x0000000182d6c1e8 0x182d6a000 + 8680 (_pthread_start + 312)

О сбое сообщается в этой строке, согласно OP:

if(dispatch_queue_ptr == NULL || idInfo->thread_handle == 0 || *dispatch_queue_ptr == NULL)

С отчетом CrashDoctor:

CrashDoctor Diagnosis: Attempted to dereference garbage pointer 0x16da23180.

Статистика приложения показывает, что приложение работало в фоновом режиме. Я не уверен, что это как-то повлияет на это расследование!

Учитывая, что idInfo разыменовывается в строке 79 выше места сбоя, я предполагаю, что причиной сбоя является разыменование dispatch_queue_ptr . Это должно означать, что проверка на ksmem_isMemoryReadable dispatch_queue_ptr в строке 80 не выполняет свою работу?

Боюсь, я еще не понимаю, как работает ksmem_isMemoryReadable и его вызываемые объекты, поэтому я застрял!

Привет, у меня такая же проблема в одном из наших приложений с часовым

KSCrash
0x100faa834
ksthread_getQueueNameKSCrash/Source/KSCrash/Recording/Tools/KSThread.c:87
KSCrash
0x100f925a0
updateThreadListKSCrash/Source/KSCrash/Recording/KSCrashCachedData.c:84
KSCrash
0x100f925a0
мониторCachedDataKSCrash/Source/KSCrash/Recording/KSCrashCachedData.c:137

Подфайл.lock:

• KSCrash/Запись (1.15.18):
  ...

Лучший

@oleksandrlysenkov вы можете воспроизвести сбой?

@Kmohamed Лично я не могу воспроизводить на своих устройствах, но каждый день я получаю журнал Crashlytics об этой ошибке, и в настоящее время это наиболее часто встречающийся сбой в 2 моих проектах.

@oleksandrlysenkov дополнительный вопрос, почему вы используете KSCrash и Crashlytics?

У меня только что случилась авария! Это произошло, когда приложение было переведено на передний план. Приложение аварийно завершало работу сразу же после переноса на передний план — пользовательский интерфейс ненадолго появлялся, а затем исчезал, что типично для аварийного завершения.

К сожалению, это была отладочная сборка, для которой у меня нет символов, но трассировка стека потока 0 и поток сбоя показывают, что делало приложение:

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: 0x00000000 at 0x000000016c2e7180
Crashed Thread:  2

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0:
0   QuartzCore                      0x00000001882086c8 CA::Layer::mark_context_changed+ 1222344 (CA::Transaction*) + 48
1   QuartzCore                      0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
2   QuartzCore                      0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
3   QuartzCore                      0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
4   QuartzCore                      0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
5   QuartzCore                      0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
6   QuartzCore                      0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
7   QuartzCore                      0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
8   QuartzCore                      0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
9   QuartzCore                      0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
10  QuartzCore                      0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
11  QuartzCore                      0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
12  QuartzCore                      0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
13  QuartzCore                      0x000000018820872c CA::Layer::mark_context_changed+ 1222444 (CA::Transaction*) + 148
14  QuartzCore                      0x0000000188210078 CA::Layer::set_visible+ 1253496 (unsigned int) + 268
15  QuartzCore                      0x0000000188170790 CA::Context::set_layer+ 599952 (void const*) + 228
16  UIKit                           0x000000018dc57818 +[_UIContextBinder createContextForBindable:withSubstrate:] + 1080
17  UIKit                           0x000000018dc57380 -[_UIContextBinder _contextForBindable:] + 132
18  UIKit                           0x000000018dc22dc8 -[_UIContextBinder updateBindableOrderWithTest:force:] + 472
19  UIKit                           0x000000018dc22a14 -[_UIContextBinder createContextsWithTest:creationAction:] + 100
20  UIKit                           0x000000018dc25bb4 -[__UICanvasLifecycleMonitor_Compatability activateEventsOnly:withContext:completion:] + 784
21  UIKit                           0x000000018e8bb72c __82-[_UIApplicationCanvas _transitionLifecycleStateWithTransitionContext:completion:]_block_invoke + 296
22  UIKit                           0x000000018dc25268 -[_UIApplicationCanvas _transitionLifecycleStateWithTransitionContext:completion:] + 432
23  UIKit                           0x000000018e6a09b8 __125-[_UICanvasLifecycleSettingsDiffAction performActionsForCanvas:withUpdatedScene:settingsDiff:fromSettings:transitionContext:]_block_invoke + 220
24  UIKit                           0x000000018e7eeae8 _performActionsWithDelayForTransitionContext + 112
25  UIKit                           0x000000018dc24c88 -[_UICanvasLifecycleSettingsDiffAction performActionsForCanvas:withUpdatedScene:settingsDiff:fromSettings:transitionContext:] + 248
26  UIKit                           0x000000018dc24624 -[_UICanvas scene:didUpdateWithDiff:transitionContext:completion:] + 368
27  UIKit                           0x000000018dc623b0 -[UIApplicationSceneClientAgent scene:handleEvent:withCompletion:] + 468
28  FrontBoardServices              0x0000000186888f24 __80-[FBSSceneImpl updater:didUpdateSettings:withDiff:transitionContext:completion:]_block_invoke.362 + 212
29  libdispatch.dylib               0x000000018397cae4 _dispatch_client_callout + 16
30  libdispatch.dylib               0x00000001839b8b0c _dispatch_block_invoke_direct$VARIANT$armv81 + 216
31  FrontBoardServices              0x00000001868bc878 __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 36
32  FrontBoardServices              0x00000001868bc51c -[FBSSerialQueue _performNext] + 404
33  FrontBoardServices              0x00000001868bcab8 -[FBSSerialQueue _performNextFromRunLoopSource] + 56
34  CoreFoundation                  0x0000000184033404 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24
35  CoreFoundation                  0x0000000184032c2c __CFRunLoopDoSources0 + 276
36  CoreFoundation                  0x000000018403079c __CFRunLoopRun + 1204
37  CoreFoundation                  0x0000000183f50da8 CFRunLoopRunSpecific + 552
38  GraphicsServices                0x0000000185f33020 GSEventRunModal + 100
39  UIKit                           0x000000018df3178c UIApplicationMain + 236
40  Charles                         0x00000001048e51b8 0x10471c000 + 1872312 (main + 76)
41  libdyld.dylib                   0x00000001839e1fc0 start + 4

Thread 2 Crashed:
0   KSCrash                         0x00000001053da84c 0x105358000 + 534604 (ksthread_getQueueName + 280)
1   KSCrash                         0x00000001053da828 0x105358000 + 534568 (ksthread_getQueueName + 244)
2   KSCrash                         0x0000000105397bb0 0x105358000 + 261040 (updateThreadList + 436)
3   KSCrash                         0x0000000105397710 0x105358000 + 259856 (monitorCachedData + 56)
4   libsystem_pthread.dylib         0x0000000183cb1220 _pthread_body + 272
5   libsystem_pthread.dylib         0x0000000183cb1110 _pthread_body + 0

Thread 3 name:  KSCrash Exception Handler (Secondary)
Thread 3:
0   libsystem_kernel.dylib          0x0000000183aefe08 mach_msg_trap + 8
1   libsystem_kernel.dylib          0x0000000183aefc80 mach_msg + 72
2   KSCrash                         0x00000001053a465c 0x105358000 + 312924 (handleExceptions + 268)
3   libsystem_pthread.dylib         0x0000000183cb1220 _pthread_body + 272
4   libsystem_pthread.dylib         0x0000000183cb1110 _pthread_body + 0

Thread 4 name:  KSCrash Exception Handler (Primary)
Thread 4:

@Kmohamed Мы используем Crashlytics для общей регистрации сбоев вместе с Fabric и KSCrash внутри других инструментов, таких как XCGLogger.

Мы перешли с Crashlytics на Sentry. Все исходники Crashlatics удалены.

Сбой также появляется в XCode=>Organizer=>Crashes :: AppStore=> (выпущенная версия) => KSCrash ... Все в потоке 3, все в KSCrash ksthread_getQueueName ссылается на:

//thread_handle shouldn't be 0 also, because
    //identifier_info->dispatch_qaddr =  identifier_info->thread_handle + get_dispatchqueue_offset_from_proc(thread->task->bsd_info);
    if(dispatch_queue_ptr == NULL || idInfo->thread_handle == 0 || *dispatch_queue_ptr == NULL)
    {
        KSLOG_TRACE("This thread doesn't have a dispatch queue attached : %p", thread);
        return false;
    }

Этот выпуск появляется в нашем Sentry 10-20 раз в день.

Кажется, что наши сбои происходят после прекращения работы приложения из-за нехватки памяти из-за сборщика мусора: «Попытка разыменования указателя мусора 0x16b717180».

У всех устройств мало памяти, например: Память | Всего: 1,9 ГБ / Свободно: 55,8 МБ / Доступно: 1,7 ГБ
Вся свободная память менее 100 МБ, большинство из них менее 50 МБ

И наш дополнительный журнал Sentry с Breadcrumbs показывает события в таком порядке:

1. AppDelegate applicationDidEnterBackground () //Вызвано прекращением работы приложения OOM??
   иногда: 1б. Приложение AppDelegate...
2. Попытка разыменования мусора => CRASH Та же отметка времени, что и у последнего приложения AppDelegate...
   EXC_BAD_ACCESS
   Попытка разыменовать указатель мусора 0x16c0ab180.
   ... разное Время между
3. Заставка

Иногда (40-50% всех отчетов) сбой появляется на: AppDelegate applicationWillResignActive. Затем пользователю необходимо перезапустить приложение дважды или одному пользователю необходимо перезапустить приложение 3 раза.

Для тестирования я мог бы воспроизвести завершение приложения OOM вторым приложением переднего плана, которое просто ест память, например :
Чтобы сократить время критического использования памяти, я сначала запрашиваю половину памяти устройства, например:

-(void)eatMemoryBigChunck
{
    NSLog(@"Eating eatMemoryBigChunck");
    unsigned long dinnerLength = 1024 * 1024 * 500;
...

Внимание, попробуйте это на устройстве, ваш симулятор может совместно использовать память с вашим хостом Mac.

@kstenerud Я думаю, что это приемлемое решение для этого сбоя, пока кто-нибудь не найдет лучшее # 281

Сбой все еще появляется, @kstenerud надеюсь, вы найдете для него решение. После дополнительного расследования я обнаружил, что этот сбой возник сразу после обновления с версии 1.15.16 до 1.15.18. Я не очень хорошо разбираюсь в ObjC, но по логике это изменение вызвало сбой - http://prntscr.com/jdpc70 http://prntscr.com/jdpcrd
Ссылка на подробности об аварии: http://crashes.to/s/149088e734b

@Kmohamed Я не уверен, как ваш запрос на включение может решить проблему, которая появляется в моем приложении. Ваше изменение находится в строке 94 KSCrash.c, но сбой отображается в строке 87.

Тем не менее, единственный способ избежать сбоя, я полагаю, это использовать KSCrash версии 1.15.16.

У меня есть отчет о сбое от iTunes Connect, в котором содержится дополнительная информация, которая может оказаться полезной. Больше информации, чем я видел раньше.

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x000000016d813180
VM Region Info: 0x16d813180 is not in any region.  Bytes after previous region: 553345  Bytes before following region: 20096
      REGION TYPE                      START - END             [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      Stack                  000000016d690000-000000016d78c000 [ 1008K] rw-/rwx SM=PRV  thread 0
--->  GAP OF 0x8c000 BYTES
      Stack Guard            000000016d818000-000000016d81c000 [   16K] ---/rwx SM=NUL  

Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [0]
Triggered by Thread:  2

Thread 2 Crashed:
0   KSCrash                         0x0000000102d42280 ksthread_getQueueName + 128 (KSThread.c:87)
1   KSCrash                         0x0000000102d42268 ksthread_getQueueName + 104 (KSThread.c:80)
2   KSCrash                         0x0000000102d1b050 monitorCachedData + 288 (KSCrashCachedData.c:84)
3   libsystem_pthread.dylib         0x0000000181825220 _pthread_body + 272 (pthread.c:740)
4   libsystem_pthread.dylib         0x0000000181825110 _pthread_start + 292 (pthread.c:799)
5   libsystem_pthread.dylib         0x0000000181823b10 thread_start + 4

я тоже
то же самое!!

Это также наш крах номер один прямо сейчас.

Это главный сбой моего приложения

Та же проблема здесь. Получение этого сбоя время от времени через Sentry.

Подробности:

OS Version: iOS 11.3.1 (15E302)
Report Version: 104

Crashed Thread: 2

Application Specific Information:
Attempted to dereference garbage pointer 0x16dc8f180.

Thread 2 Crashed:
0   KSCrash                         0x10282dba8         ksthread_getQueueName (KSThread.c:87)
1   KSCrash                         0x102815a38         [inlined] updateThreadList (KSCrashCachedData.c:84)
2   KSCrash                         0x102815a38         monitorCachedData (KSCrashCachedData.c:137)
3   libsystem_pthread.dylib         0x305450220         <redacted>
4   libsystem_pthread.dylib         0x305450110         _pthread_start

@WingedDoom @xlbs-rm Если вы обновляете до последней версии sentry-cocoa 4.x.x , это должно быть исправлено там, поскольку мы сами исправили это в KSCrash.

@HazAT о, спасибо за информацию! Обновление часового действительно решило проблему.

@HazAT , вы исправили это, просто удалив функцию getQueueName, или вы нашли основную причину этого сбоя? Если да, не могли бы вы создать запрос на слияние, чтобы это было исправлено для всех?

@ harp79 Мы просто удалили его на данный момент, так как у нас не было времени полностью разобраться в проблеме.

Мы используем Sentry-Cocoa 4.1.0, и мы все еще видим эту проблему.

Кто-нибудь еще сталкивался с этим?

Ага, еще вопрос. Наш краш номер один (и почему-то шестой) по версии Crashlytics.

То же самое

Насколько я понимаю, Sentry 4.1.0 больше не использует это.