“LLDB crash”

I wrote a script that adds a lot of breakpoints to my iOS project. Each breakpoint has a command that calls some logging code and continues without stopping.During my project execution, those breakpoints are called dozens if not hundreds times a second. Unfortunately, app performance collapsed after adding those breakpoints. It's pretty much unresponsive as executing breakpoints slow things down.Is this normal? Is performance cost for breakpoints so significant?I'm pasting below part of my python script from ~/.lldb:... for funcName in funcNames: breakpointCommand = f'breakpoint set -n {funcName} -f {fileName}' lldb.debugger.HandleCommand(breakpointCommand) lldb.debugger.HandleCommand('breakpoint command add --script-type python --python-function devTrackerScripts.breakpoint_callback')def breakpoint_callback(frame, bp_loc, dict): lineEntry = frame.GetLineEntry() functionName = frame.GetDisplayFunctionName() expression = f'expr -- proofLog(lineEntry: {lineEntry}, function: {functionName})' lldb.debugg

On Sequoia it became impossible to properly debug programs using third party mDNS, multicast or broadcast, thanks to a bug? in I guess the new local network privacy feature, every send call returns no route to host. If I run the CI job, which properly packages, signs, notarizes said program, the resulting .app works fine and also requests permission to access the local network - which is impossible through lldb as it doesn't have an Info.plist, just the ***** binary itself. However this may not be the issue, see the repro method below. A fast and easy method to reproduce is using an example from this repo: https://github.com/keepsimple1/mdns-sd/ Running the query example in a good old shell without lldb (cargo run --example query _smb._tcp) starts outputting results. Then running the same binary through lldb (lldb -o run target/debug/examples/query _smb._tcp) would result in no route to host errors. I can't provide an output anymore as I was forced to downgrade. It works fi

[I've already asked this on llvm discourse, no answer yet] Can someone give me a brief intro or point me to documentation that describes how lldb handles the dyld shared cache on macOS? I’m trying to evaluate how to implement the same functionality in Valgrind. Prior to macOS 11 Big Sur Valgrind used DYLD_SHARED_REGION=avoid to force loading the libraries and then to bypass the cache and so to trigger reading the mach-o info to be able to redirect malloc/pthread functions. Without these redirs not much is working correctly.

XCode 13.3 stuck when input Chinese in lldb console

I have some python scripts that I'm using within lldb to track messages that I receive from Endpoint Security (I'm trying to track down an issue where I may not respond to an es_message_t). So I added breakpoints for es_retain_message, es_release_message, es_respond_auth_result and es_respond_flags_result. And it works great... Some of the time. But it--fairly frequently--won't trigger one of the breakpoints. I will see cases where the es_retain_message python code didn't run but the es_respond_auth_result and the es_release_message did. Or any combination thereof. And sometimes they will all be called and everything will work out fine. I'm thinking there may be something thread based. All of the breakpoints are within code blocks--one from Endpoint Security and the other as an application-specific one (a concurrent queue). The pseudo-code looks something like: // Within the ES code block ... es_retain_message(msg) ... dispatch_async(localConcurrentQueue, ^{ ... es_respond_auth_result(msg) // or es_r