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

I watched a WWDC talk on LLDB, and they showed a nice trick of calling CATransaction.flush() from the debugger, to push changes to a UIView to the screen, even when the program was paused. Is there is a similar thing we can do with Metal? I'm using MTKView, but I can change to a lower level if that's required. The MTKView is paused, so I'm using setNeedsDisplay. As usual, I implement the draw delegate method to encode and commit a command buffer. If I do this from LLDB: metalView.setNeedsDisplay() CATransaction.flush() I can see that causes my draw function to run, but nothing shows up on screen. Is there something else we can do to flush those metal commands to the GPU and see them on screen while stepping through the program with the debugger?

Is there a way I can use the lldb user defined commands, which I can load from a KDK, to determine how much memory my kext has consumed? Is there a way to figure out what size blocks they are? I have already run the showallclasses command and the output has assured me that I am not leaking any objects which are defined by my driver's classes. Thanks, Tim

I am breaking within a switch case (within a method) and lldb is not able to p or po my local vars. I have checked both optimization flags and they are set to none.Interestingly, I *am* able to po variables outside the switch and properties of the containing struct.XCode 9.2, Swift 4