“LLDB crash”

Ditto, started seeing this today.result = SecItemAdd((__bridge CFDictionaryRef)[self dictionaryToSecItemFormat:keychainItemData], NULL);(lldb) p result(OSStatus) $1 = -34018😢

No solution, sorry, but I have exactly the same problem. I can debug successfully a local program on Sonoma 14.2.1 on an M2, but when trying to debug the same code/program on Sonoma 14.2.1 on a 2019 Intel i5, I repeatedly get the lost connection outcome after setting a breakpoint at main(): (lldb) target create factorial Current executable set to '/Users/chris/src/showc/showc/src/factorial' (x86_64). (lldb) br set -n main Breakpoint 1: where = factorial`main + 22 at factorial.c:30:9, address = 0x0000000100000e96 (lldb) run Process 85314 launched: '/Users/chris/src/showc/showc/src/factorial' (x86_64) Process 85314 exited with status = -1 (0xffffffff) lost connection The frequent suggestion of using settings set plugin.process.gdb-remote.packet-timeout 300 has no effect.

Thank you for not giving up!The error is not directly reproducible. It occurs intermittenly, days apart. Usually, but not always, in relation to Sleep. I have gotten the error on my iMac and my MacBook. The application accesses a shared file on a Linux device on my LAN.I had been getting occasional, random xxxx has quit unexpectedly for a long time. I concluded it was due to a network problem because I could reproduce it by turning WiFi off. In December, I added do-try-catch (tested through WiFi disconnect). But the errors continued, so I ran it from inside the package in Terminal. That's when I saw the Bus error: 10 and, with help of this board, discovered the Crash Report. Whew!Whatever is wrong, I think I injected it during December do-try-catch changes. But, part of debugging is asking How would I intentionally create that error?. I'm coming up dry on that question because Swift keeps coders a safe distance from memory allocation/pointers.A memory leak is a possibility, but Acti

Can you file a bug with this information? (Stacktrace and the fact that it goes away with CLANG_ENABLE_MODULE_DEBUGGING)It also looks like you may have some python LLDB script being interpreted here, so if you could include any that might be involved that would be helpful.

Nevermind, somehow I had an error in the storyboard. http://stackoverflow.com/questions/26442414/libcabi-dylib-terminating-with-uncaught-exception-of-type-nsexception-lldb fixed it.

Thanks for bringing this over to the Apple Developer Forums. On Swift Forums you wrote: This isn’t actually crashing the app Ah, confusing. There are multiple instances of code like this and some of them trap using fatalError(…) while others just log. [quote='802423021, interferon, /thread/802423, /profile/interferon'] Is there a way I can set a breakpoint to catch this where it happens? [/quote] Try this: (lldb) br set -s libswiftos.dylib -n os_log I’m not 100% sure it’ll hit this breakpoint but, if it does, the backtrace should help you understand how you got there. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I have the same problem. Did everything according to the WWDC video and I can trigger execution via lldb _simulateLaunchForTaskWithIdentifier, but other than that, it's never executed. Is there any way to analyze whats going on?

Inspecting the UIVisualEffectView, it looks like the cornerConfiguration property is in fact available, but it just hasn't been exposed as a public API yet. (lldb) po [self cornerConfiguration]

The crash dump says the pointer is pointing to a gap in the VM space of size 0x4000.Here's a bit more data:Process 626 stopped * thread #12, stop reason = EXC_BAD_ACCESS (code=1, address=0x106941224) frame #0: 0x00000001006e72a0 iSH`cpu_run [inlined] __mem_read(mem=<unavailable>, addr=<unavailable>, size=4) at memory.h:105 [opt] 102 void *ptr = __mem_read_ptr(mem, addr); 103 if (ptr == NULL) 104 return false; -> 105 memcpy(out, ptr, size); 106 return true; 107 } 108 #define mem_read(mem, addr, value) __mem_read(mem, addr, (value), sizeof(*(value))) Target 0: (iSH) stopped. (lldb) c Process 626 resuming Process 626 stopped * thread #12, stop reason = EXC_BAD_ACCESS (code=1, address=0x106941224) frame #0: 0x00000001006e72a0 iSH`cpu_run [inlined] __mem_read(mem=<unavailable>, addr=<unavailable>, size=4) at memory.h:105 [opt] 102 void *ptr = __mem_read_ptr(mem, addr); 103 if (ptr == NULL) 104 return false; -> 105 memcpy(out, ptr, size); 106 return true; 107 } 108 #d

But what if I don't download the archive builds from Xcode Cloud and don't have them locally? Does that mean that I won't be able to symbolicate crash? I thought the crashes would be symbolicated in the cloud. It's not the case? When you submit your app to the App Store, there's an option for you to include symbol information as part of the app for that upload. When you do so, crash reports that appear in your Xcode Organizer for that app version will be symbolicated for you already. That's a feature of the App Store, and not specific to builds created and uploaded through Xcode Cloud. However, that doesn't mean you shouldn't download the archives from Xcode Cloud, that is still a best practice. One valuable part of that is access to the dSYMs, which are incredibly detailed debugging assets. While using the dSYMs for symbolication is one function they serve, they also enable significant debugging capabilities using LLDB that aren't possible without them. The symbol informat