LLDB crash

Does the crash happen if you start the app within lldb? If not, one way to investigate this is to add a pause call to the start of your app. You can then launch it from the Finder and it’ll stop, at which point you can attach to it from lldb. That should reproduce the problem, because the app was started in the standard environment, while allowing you to investigate it in the debugger. Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Here's the output of the debug error when it crashes: I'm also receiving the following failed assertion: wiftData/ModelContext.swift:3253: Fatal error: Failed to identify a store that can hold instances of SwiftData._KKMDBackingData from [:] error: Assertion failed: (byte_size > 0 && byte_size <= 8 && GetMaxU64 invalid byte_size!), function GetMaxU64, file DataExtractor.cpp, line 527 Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it): 0 LLDB 0x0000000115319aac llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 56 1 LLDB 0x0000000114e7a198 lldb_private::lldb_assert(bool, char const*, char const*, char const*, unsigned int) + 148 2 LLDB 0x0000000114e73818 lldb_private::DataExtractor::GetMaxU64(unsigned long long*, unsigned long) const + 72 3 LLDB 0x0000000114d7ded0 lldb_private::CompilerType::GetValueAsScalar(lldb_private::DataExtractor const&

I searched the Xamarin bugzilla and found this bug that includes a small sample app: https://bugzilla.xamarin.com/show_bug.cgi?id=34631It crashes in the same way our app does within Xcode but runs ok from Finder or when launched from command line lldb.

and crash on iOS 7.1 Simulaotor when using Xcode 6.4.In my testing it works with the 7.1 simulator if you target a 64-bit CPU (like iPhone 5s) but fails, as you’ve described, when targeting a 32-bit CPU.I suspect you’re being bitten by a limitation of $arg1, namely, that it always maps to a register. On i386, which is what the 32-bit simulator uses, parameters are passed on the stack, not in a registers, and thus aren’t available via $argXXX notation. Rather, you have to dump the stack and work things out from there. Here’s an example, assuming you’re stopped at the first instruction of objc_exception_throw: (lldb) po $arg1 error: use of undeclared identifier '$arg1' error: 1 errors parsing expression (lldb) # Dump 8 4-bit words in hex from the top of the stack. (lldb) m r -c 8 -s 4 -f x $esp 0xbff3454c: 0x007d5fbb 0x79c55090 0x008de3d0 0x000cc038 0xbff3455c: 0x79c55110 0x00000000 0x008dd82c 0x0091b940 (lldb) # The first word is the return address; the second is th

@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”.

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

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

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.