في KSThread.c ، EXC_BAD_ACCESS
-> if (dispatch_queue_ptr == NULL || idInfo-> thread_handle == 0 || * dispatch_queue_ptr == NULL)
{
KSLOG_TRACE ("هذا الخيط ليس به قائمة انتظار إرسال مرفقة:٪ p" ، مؤشر ترابط) ؛
عودة كاذبة؛
}
تحطمت: الموضوع
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
هذا هو الانهيار رقم 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 ، وأنا أحاول استخدام cocoapods.
@ 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
و callees حتى الآن ، لذلك أنا عالق الآن!
مرحبًا ، لدي نفس المشكلة في أحد تطبيقاتنا مع الحارس
كسكراش
0x100faa834
ksthread_getQueueNameKSCrash / Source / KSCrash / Recording / Tools / KSThread.c: 87
كسكراش
0x100f925a0
updateThreadListKS تحطم / المصدر / KSCrash / Recording / KSCrashCachedData.c: 84
كسكراش
0x100f925a0
monitorCachedDataKSCrash / Source / KSCrash / Recording / KSCrashCachedData.c: 137
Podfile.lock:
أفضل
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 ... All on Thread 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 مرة في اليوم.
يبدو أن أعطالنا تحدث بعد انتهاء تطبيق "خارج الذاكرة" بسبب مشاركة Garbadge Collector: "محاولة إلغاء إشارة مؤشر القمامة 0x16b717180."
جميع الأجهزة بها ذاكرة منخفضة ، مثل: Memory | الإجمالي: 1.9 جيجا بايت / مجانًا: 55.8 ميجا بايت / قابلة للاستخدام: 1.7 جيجا بايت
كل الذاكرة المجانية أقل من 100 ميجابايت ، معظمها أقل من 50 ميجابايت
ويظهر تسجيل الحارس الإضافي باستخدام فتات الخبز الأحداث بهذا الترتيب:
في بعض الأحيان (40-50٪ من جميع التقارير) يظهر العطل على: AppDelegate applicationWillResignActive. من يحتاج المستخدم إلى إعادة تشغيل التطبيق مرتين أو يحتاج مستخدم واحد إلى إعادة تشغيل التطبيق 3 مرات.
للاختبار ، يمكنني إعادة إنتاج OOM App Termination من خلال تطبيق أمامي ثانٍ يأكل الذاكرة فقط مثل: 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 المضيف.
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
ومع ذلك ، فإن الطريقة الوحيدة لتفادي الانهيار ، كما أفترض ، هي استخدام الإصدار 1.15.16 من KSCrash.
لقد تلقيت تقرير تعطل من 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 لم يعد يستخدم هذا بعد الآن.
التعليق الأكثر فائدة
HazAT هل أصلحت هذا بمجرد إزالة وظيفة getQueueName أم أنك عثرت على السبب الجذري لهذا التعطل؟ إذا كان الأمر كذلك ، فهل تمانع في إنشاء طلب سحب بحيث يتم إصلاح ذلك للجميع؟