KSThread.cでは、EXC_BAD_ACCESS
-> if（dispatch_queue_ptr == NULL || idInfo-> thread_handle == 0 || * dispatch_queue_ptr == NULL）
{{
KSLOG_TRACE（ "このスレッドにはディスパッチキューがアタッチされていません：％p"、スレッド）;
falseを返します。
}
クラッシュ：スレッド
0 KSCrash 0x10056738c ksthread_getQueueName（KSThread.c：82）
1 KSCrash 0x100567370 ksthread_getQueueName（KSThread.c：75）
2 KSCrash 0x10053f6c8 monitorCachedData（KSCrashCachedData.c：84）
3 libsystem_pthread.dylib 0x18d021850
4 libsystem_pthread.dylib 0x18d021760 _pthread_start + 282
5 libsystem_pthread.dylib 0x18d01ed94 thread_start + 4
ferrous777
全てのコメント30件
これは私の一番のクラッシュです。誰かがこの問題を見てください。 または、このプロジェクトの独自のブランチを作成する必要がありますか？
ferrous777
2017年03月24日
私はここ数週間仕事で忙しすぎました（新しい仕事）。 誰かがPRをした場合、私は通常それらをすばやくマージします！
kstenerud
2017年03月24日
さて、ありがとう！
ferrous777
2017年03月24日
@ ferrous777運がいい？ 私もこのクラッシュを見ています。
この問題を再現する方法がわかりませんが、 thread_identifier_info_t.dispatch_qaddrから取得したdispatch_queue_ptrが偽の場所を指しているようです。 KSThread_Testを追加するPR（https://github.com/kstenerud/KSCrash/pull/221）を送信しましたが、この偽のポインター動作を提供するテストを追加する方法がわかりませんでした。
edenman
2017年04月03日
e8977a426ab3ef83939a1929c9c4743ae314bcd1でこの問題が修正されるはずです。 逆参照する前に、有効なポインターをチェックしていませんでした。 これも1.15.5のタグが付けられており、私はcocoapodsにプッシュしています。
kstenerud
2017年04月03日
@kstenerudこんにちは、私はあなたのこのコミットをチェックしました
しかし、このコード行の場合：
dispatch_queue_t * dispatch_queue_ptr =（dispatch_queue_t *）idInfo-> dispatch_qaddr;
ビルド時にエラーが発生しませんでしたか？
allen8300
2018年01月12日
同じエラー/クラッシュ、バージョンを取得しました：
- 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]
oleksandrlysenkov
2018年04月09日
KSCrash1.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の逆参照だと思います。 これは、80行目のdispatch_queue_ptrのksmem_isMemoryReadableチェックがその役割を果たしていないことを意味しているに違いありませんか？
ksmem_isMemoryReadableとその呼び出し先がどのように機能するのかまだわからないので、今は行き詰まっています。
karlvr
2018年04月10日
こんにちは私は歩哨を持つ私たちのアプリの1つで同じ問題を抱えています
KSCrash
0x100faa834
ksthread_getQueueNameKSCrash / Source / KSCrash / Recording / Tools / KSThread.c：87
KSCrash
0x100f925a0
updateThreadListKSCrash / Source / KSCrash / Recording / KSCrashCachedData.c：84
KSCrash
0x100f925a0
monitorCachedDataKSCrash / Source / KSCrash / Recording / KSCrashCachedData.c：137
Podfile.lock：
- KSCrash / Recording（1.15.18）：
..。
一番
bochos-bln
2018年04月12日
@oleksandrlysenkovクラッシュを再現できますか？
Kmohamed
2018年04月17日
@Kmohamed個人的にはデバイスで再現できませんが、毎日Crashlyticsにこのバグに関するログインがあり、現在2つのプロジェクトで最も多く見られるクラッシュです。
oleksandrlysenkov
2018年04月18日
@oleksandrlysenkovは、なぜKSCrashとCrashlyticsを使用しているのかという副次的な質問ですか？
Kmohamed
2018年04月19日
クラッシュが発生しました。 アプリをフォアグラウンドするときに発生しました。 アプリはフォアグラウンドですぐにクラッシュしました。クラッシュの典型的な例として、UIが一時的に表示された後、消えました。
残念ながら、シンボルがないデバッグビルドでしたが、スレッド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 XCGLoggerなどの他のツール内で、FabricおよびKSCrashと一緒に、一般的なクラッシュロギングにCrashlyticsを使用します
oleksandrlysenkov
2018年04月20日
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に1日10〜20回表示されます。
GarbadgeCollectorが原因でメモリ不足のアプリケーションが終了した後にクラッシュが発生したようです：「ガベージポインタ0x16b717180の逆参照を試みました。」
すべてのデバイスのメモリが少なくなっています。例：メモリ| 合計：1.9 GB /無料：55.8 MB /使用可能：1.7 GB
100MB未満のすべての空きメモリそれらのほとんどは50MB未満
そして、Breadcrumbsを使用したSentryの追加のロギングは、次の順序でイベントを表示します。
- AppDelegate applicationDidEnterBackground（）// OOMアプリの終了が原因ですか??
時々：1b。 AppDelegateアプリケーション... - ガベージの逆参照を試みました=>最後のAppDelegateアプリケーションと同じタイムスタンプをクラッシュさせます...
EXC_BAD_ACCESS
ガベージポインタ0x16c0ab180の逆参照を試みました。
...間のさまざまな時間 - スプラッシュ画面
時々（すべてのレポートの40-50％）クラッシュが次の場所に表示されます：AppDelegateapplicationWillResignActive。 ユーザーがアプリを2回再起動する必要がある場合、または1人のユーザーがアプリを3回再起動する必要がある場合。
テストの場合、次のようなメモリを消費する2番目のフォアグラウンドアプリでOOMアプリの終了を再現できます： https ：//stackoverflow.com/questions/18640414/ios-alloc-objects-until-didreceivememorywarning-is-called/18641099#18641099
重要なメモリ使用量を持つ時間を短縮するために、私は最初に次のようにデバイスメモリの半分を要求します。
-(void)eatMemoryBigChunck
{
NSLog(@"Eating eatMemoryBigChunck");
unsigned long dinnerLength = 1024 * 1024 * 500;
...
デバイスでこれを試してください。シミュレータがホストMacとメモリを共有している可能性があります。
bochos-bln
2018年04月20日
@kstenerud誰かがより良いものを見つけるまで、これはこのクラッシュの許容可能な解決策だと思います＃281
Kmohamed
2018年04月20日
クラッシュはまだ表示されます、 @ kstenerudはあなたがそれの解決策を見つけることができることを願っています。 私が見つけた追加の調査の後、そのクラッシュはバージョン1.15.16から1.15.18へのアップデートの直後に現れました。 私はObjCがあまり得意ではありませんが、論理的にはこの変更によりクラッシュが発生しました-http： //prntscr.com/jdpc70 http://prntscr.com/jdpcrd
クラッシュに関する詳細へのリンク：http： //crashes.to/s/149088e734b
@Kmohamedプルリクエストが問題をどのように解決できるかわかりません。これは私のアプリに表示されます。 変更はKSCrash.cの94行目にありますが、クラッシュは87行目に表示されます
しかし、クラッシュを回避する唯一の方法は、KSCrashのバージョン1.15.16を使用することだと思います。
oleksandrlysenkov
2018年05月04日
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
私もです
こっちも一緒！！
choiks14
2018年05月16日
これは、現在の私たちの一番のクラッシュでもあります。
patrikqvarnstrom
2018年06月05日
これは私のアプリのトップ1のクラッシュです
superlin
2018年06月20日
ここで同じ問題。 セントリー経由で時々このクラッシュを受け取ります。
詳細：
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
2018年07月05日
@WingedDoom @ xlbs-rm sentry-cocoa 4.x.xの最新バージョンに更新する場合は、KSCrashで修正したので、そこで修正する必要があります。
HazAT
2018年07月06日
@HazATああ、情報ありがとうございます！ 歩哨を更新すると、問題は確かに修正されました。
WingedDoom
2018年07月07日
@HazAT getQueueName機能を削除するだけでこれを修正しましたか、それともこのクラッシュの根本的な原因を見つけましたか？ もしそうなら、これがすべての人のために修正されるようにプルリクエストを作成していただけませんか？
harp79
2018年07月11日
@ harp79問題を完全に掘り下げる時間がなかったので、今のところ削除しました。
HazAT
2018年07月12日
Sentry-Cocoa 4.1.0を使用していますが、まだこの問題が発生しています。
derekmeiresonne
2018年08月22日
まだこれに出くわしている人はいますか？
rkotcherr
2018年09月13日
はい、まだ問題です。 Crashlyticsによって報告された私たちのナンバーワン（そして何らかの理由で6）のクラッシャー
tjh12c
2018年09月19日
こっちも一緒
私の理解では、Sentry4.1.0はこれをもう使用していません。
mirekp
2018年09月21日
関連する問題
chzhij5
·
17コメント
pdrtrifork
·
12コメント
happy201993
·
10コメント
kstenerud
·
4コメント
1t2t3t4t
·
3コメント
最も参考になるコメント
@HazAT getQueueName機能を削除するだけでこれを修正しましたか、それともこのクラッシュの根本的な原因を見つけましたか？ もしそうなら、これがすべての人のために修正されるようにプルリクエストを作成していただけませんか？