Kscrash: KSThread causando uma falha ao obter o nome da fila

Este é o meu acidente nº 1 agora, alguém pode olhar para este problema? ou devo fazer meu próprio ramo deste projeto?

Eu estive muito ocupado com o trabalho nas últimas semanas (novo emprego). Se alguém faz um PR, geralmente sou rápido em juntá-los!

Ok, obrigado!

@ferrous777 alguma sorte? eu também estou vendo esse crash.

Não consigo descobrir como reproduzir esse problema, mas parece que o dispatch_queue_ptr que recebemos de thread_identifier_info_t.dispatch_qaddr está apontando para um local falso. Acabei de enviar um PR que adiciona o KSThread_Test de volta ( https://github.com/kstenerud/KSCrash/pull/221 ), mas não consegui descobrir como adicionar um teste que nos daria esse comportamento de ponteiro falso.

e8977a426ab3ef83939a1929c9c4743ae314bcd1 deve corrigir esse problema. Não estava verificando um ponteiro válido antes de desreferenciar. Isso também está marcado como 1.15.5, e estou empurrando para os cocoapods.

@kstenerud Oi cara, eu verifiquei seu commit
mas para esta linha de código:
dispatch_queue_t* dispatch_queue_ptr = (dispatch_queue_t*)idInfo->dispatch_qaddr;

Você não obteve erros ao construir?

Obteve o mesmo erro/falha, versão:

- 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

Histórico:

[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]

Acabei de ver a mesma falha no 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)

A falha é relatada nesta linha, conforme o OP:

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

Com o relatório CrashDoctor:

CrashDoctor Diagnosis: Attempted to dereference garbage pointer 0x16da23180.

As estatísticas do aplicativo indicam que o aplicativo estava em segundo plano. Não tenho certeza se isso tem algum impacto nesta investigação!

Dado que idInfo é desreferenciado na linha 79 acima do local da falha, acho que é a desreferência de dispatch_queue_ptr que está causando a falha. Isso deve significar que a verificação ksmem_isMemoryReadable de dispatch_queue_ptr na linha 80 não está funcionando?

Receio não entender como ksmem_isMemoryReadable e seus callees funcionam ainda, então estou preso agora!

Oi eu tenho o mesmo problema em um de nossos aplicativos com sentry

KSCrashGenericName
0x100faa834
ksthread_getQueueNameKSCrash/Source/KSCrash/Recording/Tools/KSThread.c:87
KSCrashGenericName
0x100f925a0
updateThreadListKSCrash/Source/KSCrash/Recording/KSCrashCachedData.c:84
KSCrashGenericName
0x100f925a0
monitorCachedDataKSCrash/Source/KSCrash/Recording/KSCrashCachedData.c:137

Podfile.lock:

• KSCrash/Gravação (1.15.18):
  ...

Melhor

@oleksandrlysenkov você consegue reproduzir a falha?

@Kmohamed Pessoalmente, não consigo reproduzir em meus dispositivos, mas todos os dias recebo log no Crashlytics sobre esse bug e atualmente é uma falha que aparece mais em 2 dos meus projetos.

@oleksandrlysenkov uma pergunta secundária por que você está usando o KSCrash e o Crashlytics?

Acabei de ter o acidente acontecer comigo! Ocorreu ao colocar o aplicativo em primeiro plano. O aplicativo travou imediatamente após o primeiro plano - a interface do usuário apareceu brevemente e depois desapareceu, como é típico de uma falha.

Infelizmente, estava em uma compilação de depuração para a qual não tenho símbolos, mas o rastreamento de pilha do thread 0 e o thread com falha mostram o que o aplicativo estava fazendo:

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 Usamos Crashlytics para registro geral de falhas junto com Fabric e KSCrash dentro de outras ferramentas como XCGLogger

Mudamos do Crashlytics para o Sentry. Todas as fontes Crashlatics são removidas.

O Crash também aparece no XCode=>Organizer=>Crashes :: AppStore=> (uma versão lançada) => KSCrash ... Tudo no Thread 3, tudo em KSCrash ksthread_getQueueName referido a:

//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;
    }

Esta edição aparece em nosso Sentinela 10-20 vezes por dia.

Parece que nossos travamentos acontecem após o encerramento do aplicativo sem memória devido ao Garbadge Collector estar envolvido: "Tentativa de desreferenciar o ponteiro de lixo 0x16b717180."

Todos os dispositivos têm pouca memória, por exemplo: Memória | Total: 1,9 GB / Gratuito: 55,8 MB / Utilizável: 1,7 GB
Toda a memória livre com menos de 100 MB, a maioria deles com menos de 50 MB

E nosso Sentry Logging adicional com Breadcrumbs mostra os eventos nessa ordem:

1. AppDelegate applicationDidEnterBackground () //Causado devido ao encerramento do aplicativo OOM??
   às vezes: 1b. Aplicativo AppDelegate...
2. Tentativa de desreferenciar lixo => CRASH Mesmo carimbo de data/hora como o último aplicativo AppDelegate...
   EXC_BAD_ACCESS
   Tentativa de desreferenciar o ponteiro de lixo 0x16c0ab180.
   ... vários Tempo entre
3. Tela de abertura

Às vezes (40-50% de todos os relatórios) o Crash aparece em: AppDelegate applicationWillResignActive. Então o usuário precisa reiniciar o aplicativo duas vezes ou um usuário precisa reiniciar o aplicativo 3 vezes.

Para testar, eu poderia reproduzir o encerramento do aplicativo OOM por um segundo aplicativo em primeiro plano que apenas consome memória como: https://stackoverflow.com/questions/18640414/ios-alloc-objects-until-didreceivememorywarning-is-called/18641099#18641099
Para reduzir o tempo de uso crítico da memória, inicialmente solicito a metade da memória do dispositivo como:

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

Atenção, tente isso no dispositivo, seu simulador pode compartilhar memória com seu Mac host.

@kstenerud Acho que esta é uma solução aceitável para esta falha até que alguém encontre uma melhor # 281

A falha ainda aparece, @kstenerud espero que você possa encontrar uma solução para isso. Após uma investigação adicional que encontrei, essa falha apareceu logo após a atualização da versão 1.15.16 para 1.15.18. Não sou tão bom em ObjC, mas logicamente essa mudança fez com que o travamento aparecesse - http://prntscr.com/jdpc70 http://prntscr.com/jdpcrd
Link para detalhes sobre o acidente: http://crashes.to/s/149088e734b

@Kmohamed Não tenho certeza de como sua solicitação Pull pode resolver o problema que aparece no meu aplicativo. Sua alteração está na linha 94 do KSCrash.c, mas a falha aparece na linha 87

No entanto, a única maneira de evitar o travamento, suponho, é usar a versão 1.15.16 do KSCrash.

Eu tenho um relatório de falha do iTunes Connect que contém mais algumas informações que podem ser valiosas. Mais informações do que eu já vi.

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

eu também
mesmo aqui!!

Este também é o nosso acidente número um agora.

Esta é a principal falha do meu aplicativo

Mesma questão aqui. Recebendo esta falha de vez em quando via Sentinela.

Detalhes:

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 Se você estiver atualizando para a versão mais recente de sentry-cocoa 4.x.x isso deve ser corrigido lá, pois nós mesmos corrigimos no KSCrash.

@HazAT oh, obrigado pela informação! A atualização do sentry corrigiu o problema de fato.

@HazAT você corrigiu isso apenas removendo a funcionalidade getQueueName ou encontrou a causa raiz dessa falha? Se sim, você se importaria de criar um Pull Request para que isso seja corrigido para todos?

@harp79 Acabamos de removê-lo por enquanto, pois não tivemos tempo de investigar completamente o problema.

Estamos usando o Sentry-Cocoa 4.1.0 e ainda estamos vendo esse problema.

Alguém mais passando por isso ainda?

Sim, ainda é um problema. Nosso craque número um (e seis por algum motivo), conforme relatado pelo Crashlytics

Mesmo aqui

Meu entendimento é que o Sentry 4.1.0 não usa mais isso.