Kscrash: KSThread 导致崩溃获取队列名称

创建于 2017-02-23  ·  30评论  ·  资料来源: kstenerud/KSCrash

在 KSThread.c 中，EXC_BAD_ACCESS

-->if(dispatch_queue_ptr == NULL || idInfo->thread_handle == 0 || *dispatch_queue_ptr == NULL)
{
KSLOG_TRACE("这个线程没有附加调度队列：%p", thread);
返回假；
}

崩溃：线程
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+ 240
4 libsystem_pthread.dylib 0x18d021760 _pthread_start + 282
5 libsystem_pthread.dylib 0x18d01ed94 thread_start + 4

picture ferrous777
👍11 🎉1

最有用的评论

@HazAT您是通过删除 getQueueName 功能解决了这个问题，还是找到了导致此崩溃的根本原因？ 如果是这样，您介意创建一个拉取请求，以便为每个人解决这个问题吗？

picture harp79 于 2018-07-11
👍2

所有30条评论

这是我现在的＃1崩溃，有人可以看看这个问题吗？ 还是我应该创建自己的这个项目的分支？

ferrous777 picture ferrous777 于 2017-03-24

过去几周我一直忙于工作（新工作）。 如果有人做了 PR，我通常会很快合并它们！

kstenerud picture kstenerud 于 2017-03-24

好的谢谢！

ferrous777 picture ferrous777 于 2017-03-24

@ferrous777运气好吗？ 我也看到了这次崩溃。

我不知道如何重现这个问题，但看起来我们从thread_identifier_info_t.dispatch_qaddr获得的dispatch_queue_ptr指向一个虚假的位置。 我刚刚提交了一个 PR，将 KSThread_Test 添加回来（https://github.com/kstenerud/KSCrash/pull/221），但我不知道如何添加一个会给我们这种虚假指针行为的测试。

edenman picture edenman 于 2017-04-03

e8977a426ab3ef83939a1929c9c4743ae314bcd1 应该可以解决这个问题。 在取消引用之前它没有检查有效的指针。 这也被标记为 1.15.5，我正在推动 cocoapods。

kstenerud picture kstenerud 于 2017-04-03

@kstenerud嗨，伙计，我已经检查了你的这个提交
但是对于这行代码：
dispatch_queue_t* dispatch_queue_ptr = (dispatch_queue_t*)idInfo->dispatch_qaddr;

编译的时候没有报错吗？

allen8300 picture 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 picture oleksandrlysenkov 于 2018-04-09

我刚刚在 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取消引用。 这一定意味着第 80 行对dispatch_queue_ptr的ksmem_isMemoryReadable检查没有发挥作用？

恐怕我还不明白ksmem_isMemoryReadable及其被调用者是如何工作的，所以我现在卡住了！

karlvr picture 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/录音（1.15.18）：
    ...

最好的

bochos-bln picture bochos-bln 于 2018-04-12

@oleksandrlysenkov你能重现崩溃吗？

Kmohamed picture Kmohamed 于 2018-04-17

@Kmohamed就我个人而言，我无法在我的设备上重现，但我每天都会收到有关此错误的 Crashlytics 登录信息，目前这是我的两个项目中最常见的崩溃。

oleksandrlysenkov picture oleksandrlysenkov 于 2018-04-18
👍1

@oleksandrlysenkov一个附带问题，您为什么使用 KSCrash 和 Crashlytics ？

Kmohamed picture 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:
karlvr picture karlvr 于 2018-04-20

@Kmohamed我们在 XCGLogger 等其他工具中使用 Crashlytics 以及 Fabric 和 KSCrash 进行一般崩溃日志记录

oleksandrlysenkov picture oleksandrlysenkov 于 2018-04-20

我们从 Crashlytics 搬到了 Sentry。 删除所有 Crashlatics 源。

Crash 也出现在 XCode=>Organizer=>Crashes :: AppStore=> (a Released Version) => 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 GB / 免费：55.8 MB / 可用：1.7 GB
所有可用内存在 100 MB 以下，其中大部分在 50 MB 以下

我们的 Sentry 附加的带有面包屑的日志记录按以下顺序显示事件：

  1. AppDelegate applicationDidEnterBackground () //导致OOM App Termination??
    有时：1b。 AppDelegate 应用程序...
  2. 尝试取消引用垃圾 => CRASH 与上一个 AppDelegate 应用程序相同的时间戳...
    EXC_BAD_ACCESS
    试图取消引用垃圾指针 0x16c0ab180。
    ... 各种时间之间
  3. 启动画面

有时（所有报告的 40-50%）崩溃出现在：AppDelegate applicationWillResignActive。 比用户需要重新启动应用程序两次或一个用户需要重新启动应用程序 3 次。

对于测试，我可以通过第二个前台应用程序重现 OOM 应用程序终止，它只吃内存，例如： https ://stackoverflow.com/questions/18640414/ios-alloc-objects-until-didreceivememorywarning-is-call/18641099#18641099
为了减少关键内存使用的时间，我最初请求设备内存的一半，例如：

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

注意在设备上试试这个，你的模拟器可能与你的主机 Mac 共享内存。

bochos-bln picture bochos-bln 于 2018-04-20

@kstenerud我认为这是一个可接受的解决方案，直到有人找到更好的解决方案 #281

Kmohamed picture 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 行

然而，我认为避免崩溃的唯一方法是使用 1.15.16 版的 KSCrash。

oleksandrlysenkov picture 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
karlvr picture karlvr 于 2018-05-11

我也是
同样在这里！！

choiks14 picture choiks14 于 2018-05-16

这也是我们目前的第一个崩溃。

patrikqvarnstrom picture patrikqvarnstrom 于 2018-06-05

这是我的应用程序的第一个崩溃

superlin picture superlin 于 2018-06-20

这里同样的问题。 通过 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 picture WingedDoom 于 2018-07-05

@WingedDoom @xlbs-rm 如果您更新到最新版本的sentry-cocoa 4.x.x这应该在那里修复，因为我们自己在 KSCrash 中修复了它。

HazAT picture HazAT 于 2018-07-06
👍2

@HazAT哦，谢谢你的信息！ 更新哨兵确实解决了这个问题。

WingedDoom picture WingedDoom 于 2018-07-07
🎉2

@HazAT您是通过删除 getQueueName 功能解决了这个问题，还是找到了导致此崩溃的根本原因？ 如果是这样，您介意创建一个拉取请求，以便为每个人解决这个问题吗？

harp79 picture harp79 于 2018-07-11
👍2

@harp79我们暂时将其删除，因为我们没有时间完全深入研究这个问题。

HazAT picture HazAT 于 2018-07-12

我们正在使用 Sentry-Cocoa 4.1.0，我们仍然看到这个问题。

derekmeiresonne picture derekmeiresonne 于 2018-08-22
😕1

还有其他人跑过这个吗？

rkotcherr picture rkotcherr 于 2018-09-13

是的，还是个问题。 Crashlytics 报告的我们排名第一（出于某种原因是第六名）的崩溃者

tjh12c picture tjh12c 于 2018-09-19

同样在这里

我的理解是 Sentry 4.1.0 不再使用这个了。

mirekp picture mirekp 于 2018-09-21
👍1
此页面是否有帮助？
0 / 5 - 0 等级

相关问题

kstenerud picture kstenerud  ·  4评论
pdrtrifork picture pdrtrifork  ·  12评论
happy201993 picture happy201993  ·  10评论
1t2t3t4t picture 1t2t3t4t  ·  3评论
chzhij5 picture chzhij5  ·  17评论