lldb

I'm using lldb as a standalone debugger in OSX. I'm trying to debug a C executable, using a text file as input. The lldb documentation specifies the following command for changing stdin to a given file: process launch -i <file> Using this command, lldb seems to ignore the specified file, instead waiting for keyboard input. Is this intended behaviour? If so; what do I need to do to actually get the process to operate on my wanted input file? tl;dr: How do I get lldb to imitate a standard terminal execution like: ./executable < <file> I got it to work as follows: lldb <executable> (lldb)

I'm embedding MonoTouch in an Xcode project, and want to stop LLDB debugger from handling SIGBUS signals, since they are used by the mono runtime. How can I do that? You can control how lldb intercepts/passes signals with the "process handle" command. For your case, you'd want to do (lldb) pro hand -p true -s false SIGBUS NAME PASS STOP NOTIFY ========== ===== ===== ====== SIGBUS true false true now the signals will be passed to your process without lldb getting in the way. The "NOTIFY" field indicates whether lldb should print that the signal was received - the default is that it will be

I'm using a breakpoint with Action "Log Message", and I want to print the row of an NSIndexPath. So I tried: cell row @indexPath.row@ but nothing gets printed. I also tried using a debugger command: expr (void)NSLog(@"indexPath row:%i", indexPath.row) but I get an error: error: property 'row' not found on object of type 'NSIndexPath *' What am I doing wrong? The dot syntax is just syntactic sugar added by the compiler. I've always disagreed with adding it to Objective-C, but some people love it. What you have to remember is that these dots are getting converted into method calls by the

I'm trying to use LLDB within Xcode 8 to debug very basic STL. I used to be able to print a vector like this: p myvector[0] to see whatever was in the first vector index. Now when I do that, I get this error: error: Couldn't lookup symbols: __ZNSt3__16vectorI9my_classNS_9allocatorIS1_EEEixEm Instead, I have to type this: p myvector.__begin_[0] in order to get any output. I tried importing the libcxx.py and unordered_multi.py scripts from the LLDB svn repository but that doesn't seem to change anything. Has anyone been able to get any useful output from LLDB with libc++?? Jim Ingham [] is an

I am using LLDB, I am wondering how to print the value in the memory 0xb0987654? Eric Xcode has a very nice Memory Browser window, which will very nicely display the contents of memory addresses. It also lets you control byte grouping and number of bytes displayed, and move back or forward a memory page: You can access it by pressing ⌘^⌥⇧M (⌘⇧M in Xcode 9 and earlier) or Debug --> Debug Workflow --> View Memory Notice the field on its bottom left corner where you can paste the memory address you want to inspect! Documentation here: https://developer.apple.com/library/ios/recipes/xcode_help

This is by far the strangest thing thats happened to me. So I have the code below in a unit test... let aStoryboard = UIStoryboard(name: "myStoryboard", bundle: nil) let viewController = aStoryboard.instantiateViewControllerWithIdentifier("myViewController") as? CustomViewController The code above is executed and viewController is nil, okay that can happen (it shouldn't be because both identifiers exist and files are linked to test targets) but yeah okay. Here's the crazy part, when I add a breakpoint, step over the lines above and then type the following into lldb viewController = aStoryboard

Previously, this was impossible (you have to write it all out by hand / create a static array / put all the values into a dictionary and read them back ... etc) But I've noticed that the latest Xcode's lldb (4.6, maybe earlier versions too) is automatically converting enum-constants to strings. My problem is that we use a lot of libraries - including Apple's own! - which use annoying public enums with no "value-to-string" method offered. So I end up having to (many, many times over) do the "well, since Mr. Library Author didn't do this, now I have to make the static array for them...". I kept