lldb

Since I updated to xcode 4.3 and let it switch my debugger over to lldb, any request to print a member variable fails with this error message: (lldb) print request error: error: reference to 'id' is ambiguous note: candidate found by name lookup is 'id' note: candidate found by name lookup is 'id' error: 1 errors parsing expression 'self' is ok: (lldb) print self (LoginViewController *) $6 = 0x1cd54d50 And other forms of printing the member variable also fail: (lldb) print self.request error: property 'request' not found on object of type 'LoginViewController *'; did you mean to access ivar

Here are my two lines of code: NSString *frontFilePath = [[NSBundle mainBundle] pathForResource:[self.bookendFileNames objectAtIndex:self.randomIndex] ofType:@"caf"]; NSLog(@"frontFilePath = %@", frontFilePath ); I put a break point on the second line and when there, I try to print it: (lldb) po frontFilePath But I get the following error: error: variable not available I'm confused because if I step over the NSLog statement, the variable does indeed print to the console. For what it's worth, I'm trying to debug the first line since sometimes it returns NULL, tho I can't, as of now, figure out

I received an error EXC_BAD_ACCESS code=2 at0xb0987654 I am wondering how to print out the value at 0xb0987654? To debug an EXC_BAD_ACCESS, you can generally find out the where the dangling pointer is by enabling zombie objects. Xcode Choose edit scheme, then Diagnostics tab in the Run section, then click the 'Zombie Objects' option. AppCode Choose edit target, and add the following environment variable: NSZombieEnabled=YES Another cause for EXC_BAD_ACCESS can be infinite recursion, which can be found by adding some logging. Update for C++: To debug dangling pointers in C++ with the Clang

I have a breakpoint that looks like this -[UITableViewCell setSelected:] and it works, but I cannot figure out how to get the value that is being passed in. I have tried -[UITableViewCell setSelected:(BOOL)what] and -[UITableViewCell setSelected:what] which do not work at all. How can I access the parameters? If this doesn't work, I'll have to make a DebugUITableViewCell just to see what's going on, which is a hassle and touches a lot of code. If you debug your code on the device the parameters when you hit your breakpoint will consistently be in registers r0, r1, and r2. If you use po $r0 you

How can I plot out variable's value in a Swift App with LLDB? Earlier it was like po variable_name Now I usually get some nasty error, like: (lldb) po a error: <EXPR>:11:5: error: use of unresolved identifier '$__lldb_injected_self' $__lldb_injected_self.$__lldb_wrapped_expr_2( ^ That error sounds like it might be because DWARF is not telling LLDB where to find your "self" object. Given the nature of Swift, LLDB needs to know the type of self in order to be able to inject an expression inside your local scope One way to find out if that is your problem is to do at the LLDB prompt: (lldb) frame

生产环境(基于docker)故障排除？ 有感于博客园三番五次翻车 https://www.cnblogs.com/JulianHuang/archive/2019/08/19/11365593.html 　　如题，有感于博客园最近多次翻车，感觉像胡子眉毛一把抓， 定位不了生产环境的问题。 抛开流程问题，思考在生产环境中如何做故障排除， 发现博客园里面这方面的文章比较少。 . Net 本身是提供了相关工具帮助我们在生产中故障排除： https://docs.microsoft.com/en-us/dotnet/framework/tools/sos-dll-sos-debugging-extension 工具的思路是在生产环境中dump出进程快照文件，通过分析快照堆栈、线程信息、异常信息判断运行状态。 这个工具依赖的文件很多很杂，国外大牛已经针对 .NetCore 制作了 工具镜像 How to Use # docker run --rm -it -v /stripe/upload/coredump:/tmp/coredump 6opuc/lldb-netcore /stripe/upload/coredump - docker宿主机上崩溃进程的coredump文件路径 Usecases # Analyze running container # 　　1.找到需要分析的容器id

I want to trace when something changes the size of self.view. What's the correct format? (lldb) po self.view (UIView *) $1 = 0x0a8aba20 <UIView: 0xa8aba20; frame = (0 0; 480 864); autoresize = W+TM+BM; layer = <CALayer: 0xa8aba50>> (lldb) watch set variable self.view.frame.size.width error: "self" is a pointer and . was used to attempt to access "view". Did you mean "self->view.frame.size.width"? (lldb) watch set variable self->view error: "view" is not a member of "(PlayViewController *) self" (lldb) watch set variable self->view.frame.size.width error: "view" is not a member of "

I am trying to resolve a "message sent to deallocated instance " error in iOS. See the LLDB-GDB command map ( http://lldb.llvm.org/lldb-gdb.html ) - you have to import a script, and the command is named malloc_info now. Obviously, malloc stack logging still needs to be turned on in the scheme options. (lldb) script import lldb.macosx.heap (lldb) malloc_info --stack-history 0x10010d680 Unfortunately, it doesn't show dealloc's - didn't GDBs malloc-history show that as well? avishic Use instruments, you'll get the exact line - (In XCode) Run it through "Product" -> "Profile". This will start