“LLDB crash”

I was able to verify the above backtrace is really the offending log: (lldb) po $x0 6935281664 (lldb) po $x1 (lldb) po $x2 17 (lldb) po $x3 6936223887 (lldb) po $x4 6157865216 (lldb) po $x5 22 (lldb) po $x6 6149505024 (lldb) po $x7 1 (lldb) x/s $x3 0x19d6e608f: CLIENT ERROR: %@ does not override -%@ and thus cannot react to catastrophic errors beyond logging them (lldb) x/22bx $x4 0x16f099100: 0x02 0x02 0x40 0x08 0x50 0x7a 0x21 0x6e 0x16f099108: 0x02 0x00 0x00 0x00 0x40 0x08 0x50 0xef 0x16f099110: 0x66 0x2f 0x01 0x00 0x00 0x00 (lldb) po 0x000000012f66ef50 viewServiceDidTerminateWithError: (lldb) po 0x000000026e217a50 TUINSRemoteViewController

without any Termination Reason or Code. Consider this snippet from your crash report: Termination Reason: RUNNINGBOARD 3735883980 Note that the termination code is in decimal: % lldb (lldb) p/x 3735883980 (long) $0 = 0x00000000dead10cc This dead10cc code is explained in Understanding the Exception Types in a Crash Report. The fact that this code is in decimal rather than hex is annoying. I know @edford is working to get that fixed, although I don’t know the current status of that effort. On the plus side, at least we include the exception code now, which is a marked improvement from the previous situation. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

@Mrfearless. Your issue actually sounds like the documented issue with Safari. Have you tried this? Safari Known Issues Safari might quit unexpectedly if iCloud Tabs are enabled. (70625636) Workaround: Bypass the Start Page by clicking a URL in a different application, such as Mail or Notes, to open Safari. In Safari > Preferences > General, set “New windows open with:” and “New tabs open with:” to “Empty Page”.

Same issue for me since the latest updates to Sequoia 15.4 and 16.2. Whenever I attach to a Simulator and try to view any variable, the LLDB RPC server crashes immediately. FB16682372 Debugging physical devices still seems to work fine.

Perhaps the issue is in PLCrashReporter, or in the interplay between PLCrashReporter and CFNetwork? Perhaps. Frankly, I don’t trust any crash reports other than Apple crash reports. See Implementing Your Own Crash Reporter for an explanation as to why. Bug number is [FB10663350] Thanks for that. Digging into the crash report a little more, I can confirm that the specific crash is caused by CFNetwork calling dispatch_source_set_timer [1] with NULL in the first parameter. Indeed, if you write a tiny test project with this code: dispatch_source_set_timer(NULL, 0, 0, 0); frame 0 of the crash will exactly match the crash report [2]: (lldb) disas -s 0x10274ac3c -c 9 libdispatch.dylib`_dispatch_source_set_runloop_timer_4CF: 0x10274ac3c <+0>: pacibsp 0x10274ac40 <+4>: stp x26, x25, [sp, #-0x50]! 0x10274ac44 <+8>: stp x24, x23, [sp, #0x10] 0x10274ac48 <+12>: stp x22, x21, [sp, #0x20] 0x10274ac4c <+16>: stp x20, x19, [

Looks like a bug, not new....See https://stackoverflow.com/questions/43635522/what-is-lldb-rpc-server-when-does-it-crash-in-xcode-why-it-crashesIf you take the time to file one, be sure to add your report # to your thread for reference, thanks and good luck.Ken

Signal 6 is SIGABRT, which likely means that something called abort() in your app. When this happens and you get that message in Xcode, you can review the thread backtraces in the debugger to see what aborted. Alternatively, you can enter the LLDB command detach, which will detach the debugger, and allow the app to continue to crash using normal means, resulting in a crash report that you can then review. — Ed Ford,  DTS Engineer

@DTS Engineer On disabling the signal handler I was able to get a crash report. ... which suggests you have a Mach exception handler that’s active even with your signal handler disabled. Is it possible to disable that? No, the exception handler is crucial to the operation of the product. Remember this is a language. We produce compiled code, catch exceptions on behalf of users, etc. This has been part of the product since the first version, in MacOS 10.0. For example, in Common Lisp, we have an API for virtual multi-threading and that facility uses the exception handler for its operation. That feature cannot be turned off. Our application is not a normal application. We have an entire programming system inside our product, and that includes catching exceptions and dealing with them programmatically. Implementing a Mach exception handler correctly is really hard, We agree. We would be happy to send you the source code for it, but we don't want to post it here. This exception handler is as old as MacOS

I have do this.If I take the name from my storyboard and run the app, crash and sgabrt.If I take the name Main, I becoes this error:2015-08-22 09:47:35.911 Kapitel2[1168:47555] [+] <ViewController: 0x7ba78de0>.writeLog:(lldb)So whats now?