KSThread causing a crash getting queue name #207

ferrous777 · 2017-02-22T23:05:27Z

in KSThread.c, EXC_BAD_ACCESS

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

Crashed: 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

ferrous777 · 2017-03-24T00:11:09Z

This is my #1 crash now, can someone please look at this issue? or should I make my own branch of this project?

kstenerud · 2017-03-24T00:13:46Z

I've been too busy with work for the past few weeks (new job). If someone makes a PR, I'm usually quick to merge them!

ferrous777 · 2017-03-24T00:14:33Z

Okay, thanks!

edenman · 2017-04-02T22:21:39Z

@ferrous777 any luck? i'm also seeing this crash.

I can't figure out how to repro this issue, but it looks like the dispatch_queue_ptr that we get from thread_identifier_info_t.dispatch_qaddr is pointing at a bogus location. I just submitted a PR that adds the KSThread_Test back (#221) but I couldn't figure out how to add a test that would give us this bogus pointer behavior.

kstenerud · 2017-04-03T01:57:24Z

e8977a4 should fix this issue. It wasn't checking for a valid pointer before dereferencing. This is also tagged 1.15.5, and I'm pushing to cocoapods.

allen8300 · 2018-01-12T03:21:05Z

@kstenerud Hi man, I've checked your this commit
but for this line of code:
dispatch_queue_t* dispatch_queue_ptr = (dispatch_queue_t*)idInfo->dispatch_qaddr;

Didn't you get errors when building?

oleksandrlysenkov · 2018-04-09T08:47:35Z

Got the same error/crash, version:

- 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

logs:

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

karlvr · 2018-04-10T10:05:14Z

I have just seen the same crash in 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)

The crash is reported on this line, as per the OP:

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

With the CrashDoctor reporting:

CrashDoctor Diagnosis: Attempted to dereference garbage pointer 0x16da23180.

The application stats indicate that the app was in the background. I'm not sure if that has any impact on this investigation!

Given that idInfo is dereferenced on line 79 above the crash-site, I guess it's the dispatch_queue_ptr dereference that is causing the crash. This must mean that the ksmem_isMemoryReadable check of dispatch_queue_ptr on line 80 is not doing its job?

I'm afraid I don't understand how ksmem_isMemoryReadable and its callees work yet, so I'm stuck now!

bochos-bln · 2018-04-12T10:11:53Z

Hi i have the same issue in one of our apps with sentry

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):
...

Best

Kmohamed · 2018-04-17T15:11:58Z

@oleksandrlysenkov are you able to reproduce the crash ?

oleksandrlysenkov · 2018-04-18T13:43:30Z

@Kmohamed Personally I'm not able to reproduce on my devices, but every day I receive log in Crashlytics about this bug and currently it's a most appearing crash on 2 of my projects.

Kmohamed · 2018-04-19T07:47:00Z

@oleksandrlysenkov a side question why you are using KSCrash and Crashlytics ?

karlvr · 2018-04-20T08:15:38Z

I have just had the crash happen to me! It occurred when foregrounding the app. The app crashed immediately upon foregrounding—the UI appeared briefly and then disappeared, as typical for a crash.

Unfortunately it was on a debug build for which I don't have symbols, but the stack trace of thread 0 and the crashing thread show what the app was doing:

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:

oleksandrlysenkov · 2018-04-20T08:17:41Z

@Kmohamed We use Crashlytics for general crash-logging together with Fabric and KSCrash inside of other tools like XCGLogger

bochos-bln · 2018-04-20T08:44:15Z

We moved from Crashlytics to Sentry. All Crashlatics Sources are removed.

The Crash also appears in XCode=>Organizer=>Crashes :: AppStore=> (a Released Version) => KSCrash ... All on Thread 3, all in KSCrash ksthread_getQueueName reffered to:

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

This Issue appears in our Sentry 10-20 Times a Day.

It seems that our crashes happen after Out Of Memory Application Termination due Garbadge Collector is involved: "Attempted to dereference garbage pointer 0x16b717180."

All Devices have low Memory e.g.: Memory | Total: 1.9 GB / Free: 55.8 MB / Usable: 1.7 GB
All Free Memory under 100 MB most of them under 50 MB

And our Sentry additional Logging with Breadcrumbs show events in that order:

AppDelegate applicationDidEnterBackground () //Caused due OOM App Termination??
sometimes: 1b. AppDelegate application...
Attempted to dereference garbage => CRASH Same Timestamp like the last AppDelegate application...
EXC_BAD_ACCESS
Attempted to dereference garbage pointer 0x16c0ab180.
... various Time between
Splash Screen

Sometimes (40-50% of all Reports) the Crash appears on: AppDelegate applicationWillResignActive. Than the User needs to restart the App twice or one User needed to restart the App 3 times.

For Testing i could reproduce OOM App Termination by a second foreground App wich just eats memory like: https://stackoverflow.com/questions/18640414/ios-alloc-objects-until-didreceivememorywarning-is-called/18641099#18641099
To reduce the time for having critical Memory usage i initially request the half of the device memory like:

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

Attention try this on Device, your simulator may shares memory with your host Mac.

Kmohamed · 2018-04-20T09:14:41Z

@kstenerud I think this an acceptable solution for this crash until someone find a better one #281

oleksandrlysenkov · 2018-05-04T14:37:36Z

The crash still appears, @kstenerud hope you can find a solution for it. After an additional investigation I found, that crash appeared right after update from version 1.15.16 to 1.15.18. I'm not so good in ObjC, but logically this change caused the crash to appear - http://prntscr.com/jdpc70 http://prntscr.com/jdpcrd
Link to details about the crash: http://crashes.to/s/149088e734b

@Kmohamed I'm not sure how your Pull request can solve the problem, that appears in my app. Your change is on line 94 of KSCrash.c, but crash appears on line 87

Yet the only way how to avoid the crash, I suppose, is to use version 1.15.16 of KSCrash.

karlvr · 2018-05-11T09:55:22Z

I've got a crash report from iTunes Connect that has some more information in it that might be valuable. More info than I've seen before.

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-16T07:38:25Z

me too
same here!!

ebbe-minecraft · 2018-06-05T08:01:42Z

This is also our number one crash right now.

superlin · 2018-06-20T04:08:32Z

This is top one crash of my app

WingedDoom · 2018-07-05T20:49:39Z

Same issue here. Receiving this crash from time to time via Sentry.

Details:

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

HazAT · 2018-07-06T08:20:56Z

@WingedDoom @xlbs-rm If you updating to the latest version of sentry-cocoa 4.x.x this should be fixed there since we fixed it in KSCrash ourselves.

WingedDoom · 2018-07-07T11:04:38Z

@HazAT oh, thank you for the information! Updating sentry fixed the issue indeed.

harp79 · 2018-07-11T12:25:56Z

@HazAT did you fix this by just removing getQueueName functionality or did you find the root cause for this crash? If so would you mind creating a Pull Request so that this gets fixed for everyone?

HazAT · 2018-07-12T06:58:15Z

@harp79 We just removed it for now since we did not have the time to fully dig into the issue.

derekmeiresonne · 2018-08-22T20:34:33Z

We're using Sentry-Cocoa 4.1.0 and we're still seeing this issue.

rkotcherr · 2018-09-13T12:00:25Z

Anybody else running across this still?

tjh12c · 2018-09-19T21:36:31Z

Yep, still an issue. Our number one (and six for some reason) crasher as reported by Crashlytics

mirekp · 2018-09-21T13:14:21Z

Same here

My understanding is that the Sentry 4.1.0 doesn't use this any more.

edenman mentioned this issue Apr 2, 2017

"Attempted to dereference garbage pointer" crash in KSCrash 1.15.3 #209

Closed

sola92 mentioned this issue Apr 17, 2017

Bump KSCrash version getsentry/sentry-react-native#36

Closed

edenman mentioned this issue Jun 3, 2017

Replacing/forking KSCrash? getsentry/sentry-cocoa#166

Closed

oleksandrlysenkov mentioned this issue Apr 17, 2018

KSCrashCachedData causes a crash inside ksthread_getQueueName #280

Open

Kmohamed mentioned this issue Apr 20, 2018

Temporally Fixing dispatch-Queues names crash #281

Closed

bamx23 mentioned this issue May 16, 2018

Disable queue names searching by default #286

Merged

kstenerud closed this as completed in #286 Oct 17, 2018

mduncan26 mentioned this issue Oct 17, 2019

[XRAY-3304] Fixing thread bad access crash inside KSCrash MindscapeHQ/raygun4apple#29

Merged

indragiek mentioned this issue Apr 29, 2022

Apply patch for SentryCrashCachedData getsentry/sentry-cocoa#1790

Merged

5 tasks

indragiek mentioned this issue Dec 30, 2023

fix: Remove dispatch queue metadata collection to fix crash getsentry/sentry-cocoa#3522

Merged

7 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

KSThread causing a crash getting queue name #207

KSThread causing a crash getting queue name #207

ferrous777 commented Feb 22, 2017

ferrous777 commented Mar 24, 2017

kstenerud commented Mar 24, 2017

ferrous777 commented Mar 24, 2017

edenman commented Apr 2, 2017

kstenerud commented Apr 3, 2017

allen8300 commented Jan 12, 2018

oleksandrlysenkov commented Apr 9, 2018 •

edited

karlvr commented Apr 10, 2018

bochos-bln commented Apr 12, 2018

Kmohamed commented Apr 17, 2018

oleksandrlysenkov commented Apr 18, 2018

Kmohamed commented Apr 19, 2018

karlvr commented Apr 20, 2018

oleksandrlysenkov commented Apr 20, 2018

bochos-bln commented Apr 20, 2018 •

edited

Kmohamed commented Apr 20, 2018 •

edited

oleksandrlysenkov commented May 4, 2018

karlvr commented May 11, 2018

choiks14 commented May 16, 2018

ebbe-minecraft commented Jun 5, 2018

superlin commented Jun 20, 2018

WingedDoom commented Jul 5, 2018

HazAT commented Jul 6, 2018

WingedDoom commented Jul 7, 2018

harp79 commented Jul 11, 2018

HazAT commented Jul 12, 2018

derekmeiresonne commented Aug 22, 2018

rkotcherr commented Sep 13, 2018

tjh12c commented Sep 19, 2018 •

edited

mirekp commented Sep 21, 2018 •

edited

KSThread causing a crash getting queue name #207

KSThread causing a crash getting queue name #207

Comments

ferrous777 commented Feb 22, 2017

ferrous777 commented Mar 24, 2017

kstenerud commented Mar 24, 2017

ferrous777 commented Mar 24, 2017

edenman commented Apr 2, 2017

kstenerud commented Apr 3, 2017

allen8300 commented Jan 12, 2018

oleksandrlysenkov commented Apr 9, 2018 • edited

karlvr commented Apr 10, 2018

bochos-bln commented Apr 12, 2018

Kmohamed commented Apr 17, 2018

oleksandrlysenkov commented Apr 18, 2018

Kmohamed commented Apr 19, 2018

karlvr commented Apr 20, 2018

oleksandrlysenkov commented Apr 20, 2018

bochos-bln commented Apr 20, 2018 • edited

Kmohamed commented Apr 20, 2018 • edited

oleksandrlysenkov commented May 4, 2018

karlvr commented May 11, 2018

choiks14 commented May 16, 2018

ebbe-minecraft commented Jun 5, 2018

superlin commented Jun 20, 2018

WingedDoom commented Jul 5, 2018

HazAT commented Jul 6, 2018

WingedDoom commented Jul 7, 2018

harp79 commented Jul 11, 2018

HazAT commented Jul 12, 2018

derekmeiresonne commented Aug 22, 2018

rkotcherr commented Sep 13, 2018

tjh12c commented Sep 19, 2018 • edited

mirekp commented Sep 21, 2018 • edited

oleksandrlysenkov commented Apr 9, 2018 •

edited

bochos-bln commented Apr 20, 2018 •

edited

Kmohamed commented Apr 20, 2018 •

edited

tjh12c commented Sep 19, 2018 •

edited

mirekp commented Sep 21, 2018 •

edited