Kscrash: KSThread menyebabkan crash mendapatkan nama antrian

Dibuat pada 23 Feb 2017  ·  30Komentar  ·  Sumber: kstenerud/KSCrash

di KSThread.c, EXC_BAD_ACCESS

-->if(dispatch_queue_ptr == NULL || idInfo->thread_handle == 0 || *dispatch_queue_ptr == NULL)
{
KSLOG_TRACE("Utas ini tidak memiliki antrian pengiriman yang terpasang : %p", utas);
kembali salah;
}

Rusak: Benang
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

Komentar yang paling membantu

@HazAT apakah Anda memperbaikinya dengan hanya menghapus fungsionalitas getQueueName atau apakah Anda menemukan akar penyebab crash ini? Jika demikian, maukah Anda membuat Permintaan Tarik agar ini diperbaiki untuk semua orang?

picture harp79 pada 11 Jul 2018
👍2

Semua 30 komentar

Ini adalah kerusakan # 1 saya sekarang, dapatkah seseorang melihat masalah ini? atau haruskah saya membuat cabang sendiri dari proyek ini?

ferrous777 picture ferrous777 pada 24 Mar 2017

Saya terlalu sibuk dengan pekerjaan selama beberapa minggu terakhir (pekerjaan baru). Jika seseorang membuat PR, saya biasanya cepat menggabungkannya!

kstenerud picture kstenerud pada 24 Mar 2017

Oke terima kasih!

ferrous777 picture ferrous777 pada 24 Mar 2017

@ferrous777 beruntung? saya juga melihat kecelakaan ini.

Saya tidak tahu cara mengulangi masalah ini, tetapi sepertinya dispatch_queue_ptr yang kami dapatkan dari thread_identifier_info_t.dispatch_qaddr menunjuk ke lokasi palsu. Saya baru saja mengirimkan PR yang menambahkan KSThread_Test kembali ( https://github.com/kstenerud/KSCrash/pull/221 ) tetapi saya tidak tahu cara menambahkan tes yang akan memberi kita perilaku penunjuk palsu ini.

edenman picture edenman pada 3 Apr 2017

e8977a426ab3ef83939a1929c9c4743ae314bcd1 harus memperbaiki masalah ini. Itu tidak memeriksa penunjuk yang valid sebelum melakukan dereferensi. Ini juga ditandai 1.15.5, dan saya mendorong ke cocoapods.

kstenerud picture kstenerud pada 3 Apr 2017

@kstenerud Hai kawan, saya sudah memeriksa komit Anda ini
tetapi untuk baris kode ini:
dispatch_queue_t* dispatch_queue_ptr = (dispatch_queue_t*)idInfo->dispatch_qaddr;

Apakah Anda tidak mendapatkan kesalahan saat membangun?

allen8300 picture allen8300 pada 12 Jan 2018

Mendapat kesalahan/kerusakan yang sama, versi:

- 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

log:

[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 pada 9 Apr 2018

Saya baru saja melihat crash yang sama di 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)

Kerusakan dilaporkan pada baris ini, sesuai OP:

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

Dengan pelaporan CrashDoctor:

CrashDoctor Diagnosis: Attempted to dereference garbage pointer 0x16da23180.

Statistik aplikasi menunjukkan bahwa aplikasi berada di latar belakang. Saya tidak yakin apakah itu berdampak pada penyelidikan ini!

Mengingat bahwa idInfo di-dereferensi pada baris 79 di atas situs mogok, saya kira itu adalah dereferensi dispatch_queue_ptr yang menyebabkan kerusakan. Ini pasti berarti cek ksmem_isMemoryReadable dari dispatch_queue_ptr pada baris 80 tidak melakukan tugasnya?

Saya khawatir saya belum mengerti cara kerja ksmem_isMemoryReadable dan penerimanya, jadi saya buntu sekarang!

karlvr picture karlvr pada 10 Apr 2018
👍1

Hai, saya memiliki masalah yang sama di salah satu aplikasi kami dengan penjaga

KSCrash
0x100faa834
ksthread_getQueueNameKSCrash/Sumber/KSCrash/Rekaman/Alat/KSThread.c:87
KSCrash
0x100f925a0
updateThreadListKSCrash/Sumber/KSCrash/Rekaman/KSCrashCachedData.c:84
KSCrash
0x100f925a0
monitorCachedDataKSCrash/Sumber/KSCrash/Rekaman/KSCrashCachedData.c:137

Podfile.lock:

  • KSCrash/Perekaman (1.15.18):
    ...

Terbaik

bochos-bln picture bochos-bln pada 12 Apr 2018

@oleksandrlysenkov apakah Anda dapat mereproduksi crash?

Kmohamed picture Kmohamed pada 17 Apr 2018

@Kmohamed Secara pribadi saya tidak dapat mereproduksi di perangkat saya, tetapi setiap hari saya menerima log in Crashlytics tentang bug ini dan saat ini merupakan kerusakan yang paling banyak muncul di 2 proyek saya.

oleksandrlysenkov picture oleksandrlysenkov pada 18 Apr 2018
👍1

@oleksandrlysenkov pertanyaan sampingan mengapa Anda menggunakan KSCrash dan Crashlytics?

Kmohamed picture Kmohamed pada 19 Apr 2018

Saya baru saja mengalami kecelakaan itu! Itu terjadi saat menjalankan aplikasi. Aplikasi langsung mogok saat di latar depan—UI muncul sebentar lalu menghilang, seperti biasanya saat mogok.

Sayangnya itu pada build debug yang saya tidak memiliki simbol, tetapi jejak tumpukan utas 0 dan utas yang mogok menunjukkan apa yang dilakukan aplikasi:

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 pada 20 Apr 2018

@Kmohamed Kami menggunakan Crashlytics untuk crash-logging umum bersama dengan Fabric dan KSCrash di dalam alat lain seperti XCGLogger

oleksandrlysenkov picture oleksandrlysenkov pada 20 Apr 2018

Kami pindah dari Crashlytics ke Sentry. Semua Sumber Crashlatics dihapus.

Crash juga muncul di XCode=>Organizer=>Crash :: AppStore=> (Versi Dirilis) => KSCrash ... Semua di Thread 3, semua di KSCrash ksthread_getQueueName merujuk ke:

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

Masalah ini muncul di Penjaga kami 10-20 Kali Sehari.

Tampaknya kerusakan kami terjadi setelah Penghentian Aplikasi Kehabisan Memori karena Pengumpul Sampah terlibat: "Mencoba mendereferensi penunjuk sampah 0x16b717180."

Semua Perangkat memiliki Memori rendah mis: Memori | Total: 1,9 GB / Gratis: 55,8 MB / Dapat Digunakan: 1,7 GB
Semua Memori Gratis di bawah 100 MB sebagian besar di bawah 50 MB

Dan Logging tambahan Sentry kami dengan Breadcrumbs menunjukkan acara dalam urutan itu:

  1. AppDelegate applicationDidEnterBackground () // Disebabkan karena Penghentian Aplikasi OOM??
    kadang-kadang: 1b. Aplikasi Delegasi App...
  2. Mencoba mendereferensi sampah => CRASH Stempel Waktu yang Sama seperti aplikasi AppDelegate terakhir...
    EXC_BAD_ACCESS
    Mencoba mendereferensikan penunjuk sampah 0x16c0ab180.
    ... berbagai Waktu antara
  3. Layar Percikan

Terkadang (40-50% dari semua Laporan) Kerusakan muncul di: AppDelegate applicationWillResignActive. Kemudian Pengguna perlu me-restart Aplikasi dua kali atau satu Pengguna perlu me-restart Aplikasi 3 kali.

Untuk Pengujian saya dapat mereproduksi Penghentian Aplikasi OOM dengan Aplikasi latar depan kedua yang hanya memakan memori seperti: https://stackoverflow.com/questions/18640414/ios-alloc-objects-until-didreceivememorywarning-is-call/18641099#18641099
Untuk mengurangi waktu penggunaan Memori kritis, saya awalnya meminta setengah dari memori perangkat seperti:

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

Perhatian coba ini di Perangkat, simulator Anda mungkin berbagi memori dengan host Mac Anda.

bochos-bln picture bochos-bln pada 20 Apr 2018

@kstenerud Saya pikir ini solusi yang dapat diterima untuk crash ini sampai seseorang menemukan yang lebih baik #281

Kmohamed picture Kmohamed pada 20 Apr 2018

Crash masih muncul, @kstenerud semoga bisa dicarikan solusinya. Setelah penyelidikan tambahan yang saya temukan, kerusakan itu muncul tepat setelah pembaruan dari versi 1.15.16 ke 1.15.18. Saya tidak begitu baik dalam ObjC, tetapi secara logis perubahan ini menyebabkan crash muncul - http://prntscr.com/jdpc70 http://prntscr.com/jdpcrd
Tautan ke detail tentang kerusakan: http://crashes.to/s/149088e734b

@Kmohamed Saya tidak yakin bagaimana permintaan Tarik Anda dapat menyelesaikan masalah, yang muncul di aplikasi saya. Perubahan Anda ada di baris 94 dari KSCrash.c, tetapi crash muncul di baris 87

Namun satu-satunya cara untuk menghindari crash, saya kira, adalah dengan menggunakan KSCrash versi 1.15.16.

oleksandrlysenkov picture oleksandrlysenkov pada 4 Mei 2018

Saya mendapat laporan kerusakan dari iTunes Connect yang memiliki beberapa informasi lebih di dalamnya yang mungkin berharga. Lebih banyak info daripada yang pernah saya lihat sebelumnya.

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 pada 11 Mei 2018

saya juga
sama disini!!

choiks14 picture choiks14 pada 16 Mei 2018

Ini juga kecelakaan nomor satu kami sekarang.

patrikqvarnstrom picture patrikqvarnstrom pada 5 Jun 2018

Ini adalah salah satu kerusakan teratas dari aplikasi saya

superlin picture superlin pada 20 Jun 2018

Masalah yang sama di sini. Menerima crash ini dari waktu ke waktu melalui Sentry.

Detail:

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 pada 5 Jul 2018

@WingedDoom @xlbs-rm Jika Anda memperbarui ke versi terbaru sentry-cocoa 4.x.x ini harus diperbaiki di sana karena kami memperbaikinya sendiri di KSCrash.

HazAT picture HazAT pada 6 Jul 2018
👍2

@HazAT oh, terima kasih atas informasinya! Memperbarui penjaga memang memperbaiki masalah ini.

WingedDoom picture WingedDoom pada 7 Jul 2018
🎉2

@HazAT apakah Anda memperbaikinya dengan hanya menghapus fungsionalitas getQueueName atau apakah Anda menemukan akar penyebab crash ini? Jika demikian, maukah Anda membuat Permintaan Tarik agar ini diperbaiki untuk semua orang?

harp79 picture harp79 pada 11 Jul 2018
👍2

@harp79 Kami baru saja menghapusnya untuk saat ini karena kami tidak punya waktu untuk sepenuhnya menggali masalah ini.

HazAT picture HazAT pada 12 Jul 2018

Kami menggunakan Sentry-Cocoa 4.1.0 dan kami masih melihat masalah ini.

derekmeiresonne picture derekmeiresonne pada 22 Agu 2018
😕1

Adakah orang lain yang masih melintasi ini?

rkotcherr picture rkotcherr pada 13 Sep 2018

Ya, masih menjadi masalah. Penghancur nomor satu (dan enam untuk beberapa alasan) kami seperti yang dilaporkan oleh Crashlytics

tjh12c picture tjh12c pada 19 Sep 2018

Sama disini

Pemahaman saya adalah bahwa Sentry 4.1.0 tidak menggunakan ini lagi.

mirekp picture mirekp pada 21 Sep 2018
👍1
Apakah halaman ini membantu?
0 / 5 - 0 peringkat

Masalah terkait

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