LLDB crash

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

*** Assertion failure in -[FBSSerialQueue assertOnQueue], /BuildRoot/Library/Caches/com.apple.xbs/Sources/FrontBoardServices/FrontBoard-619.2/FrontBoardServices/FBSSerialQueue.m:98(lldb)

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.

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]

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.

Also just to emphasize the broken behavior. If lldb cannot report the correct data, then I'm not sure how to triage this. image list and image list report different output. One doesn't and one does list the original dylib that's already been unloaded (at least according to dyld printouts). So I think the dyld gets confused, and starts trying to return the original dylib from time to tim. (lldb) image list -b -m bar_signed_000.dylib [ 0] bar_signed_000.dylib Fri Jan 15 11:23:27 2021 dlclose(lib) <- bar_signed_000.dylib dyld: unloaded: /foo/bar_signed_000.dylib <- great dlopen(“/foo/bar_signed_001.dylib”) (lldb) image list -b -m /foo/bar_signed_000.dylib [ 0] bar_signed_000.dylib Fri Jan 15 11:23:27 2021. <- why is this still listed? it’s not in image list dyld: Mapping /foo/bar_signed_001.dylib dyld: loaded: /foo/bar_signed_001.dylib (lldb) image list -b -m Game_signed_001.dylib error: no modules found that match 'Game_signed_001.dylib’ <- dyld said it just lo

[quote='777684021, huuu, /thread/777684, /profile/huuu'] The hexadecimal value of 4294893875545978 is 0xF3F3F3F3F3F3A. [/quote] Is it? That’s not what I calculate: (lldb) p/x 4294893875545978 (long) 0x000f422ee7ccc77a (lldb) p/x -4294893875545978 (long) 0xfff0bdd118333886 I’m not entirely sure what’s going on with your code but I do have one hint to pass along: Both domainLookupStartDate and domainLookupEndDate can be nil, so you should only run this calculation if both values are valid. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com