lldb

GDB errors on macOS Mojave

一曲冷凌霜 提交于 2019-11-28 01:45:03
Environment: Mac/Mojave and GDB 8.2.1 (via homebrew). I worked through instructions https://forward-in-code.blogspot.com/2018/11/mojave-vs-gdb.html i.e.: latest GDB via brew, which solves the executable format issue sign GDB with new entitlements Additionally, I've also modified SIP to allow debugging (in Recovery OS terminal: csrutil enable --without debug ). However, I still can’t get gdb to work: (gdb) file main Reading symbols from main...done. (gdb) run Starting program: /Users/joubertold/code/Rhodus/obj/debug/main [New Thread 0x1a03 of process 5082] [New Thread 0x2803 of process 5082]

How to get NDK debugging to work in Android Studio?

不打扰是莪最后的温柔 提交于 2019-11-27 23:16:06
问题 Android Studio doesn't stop at breakpoints in C++ code, this is what i've done so far : In AndroidManifest.xml : android:debuggable="true" In build.gradle (this may be the problem): sourceSets.main { jniLibs.srcDir 'src/main/libs' jni.srcDirs = [] } task ndkBuild(type: Exec) { commandLine android.ndkDirectory.getAbsolutePath() + '\\' + 'ndk-build.cmd', '-C', file('src/main/jni').absolutePath, 'NDK_DEBUG=1' } tasks.withType(JavaCompile) { compileTask -> compileTask.dependsOn ndkBuild }

LLDB not showing source code

混江龙づ霸主 提交于 2019-11-27 20:39:01
I am trying to debug a C++ program I am writing, but when I run it in LLDB and stop the program, it only shows me the assembler, not the original source. e.g. after the crash I’m trying to debug: Process 86122 stopped * thread #13: tid = 0x142181, 0x0000000100006ec1 debug_build`game::update() + 10961, stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) frame #0: 0x0000000100006ec1 debug_build`game::update() + 10961 debug_build`game::update: -> 0x100006ec1 <+10961>: movq (%rdx), %rdx 0x100006ec4 <+10964>: movq %rax, -0xb28(%rbp) 0x100006ecb <+10971>: movq -0x1130(%rbp), %rax 0x100006ed2 <+10978>

GDB Vs LLDB debuggers

99封情书 提交于 2019-11-27 17:41:34
What is the difference between GDB & LLDB debuggers? I recently upgraded my Xcode version from 4.2 to 4.3 & started getting warning to upgrade my debugger from GDB to LLDB. infinitetape LLDB is part of the LLVM suite of tools that Apple is moving to, including Clang. There are tons of improved features, including improved performance. There's a quick intro for GDB users here: http://lldb.llvm.org/tutorial.html However... You might want to take a trip over to the forums at developer.apple.com. There's a fair bit of rumbling about issues with LLDB at the moment (in XCode 4.3.1). One nasty issue,

Random (lldb) crashes in iOS Simulator on Mac OS X 10.8.4

不问归期 提交于 2019-11-27 17:31:02
问题 I've been struggling with an weird issue for some time now. When running my app with the iOS Simulator initially closed it launches correctly. But if I then run it again without closing the simulator it crashes and just prints (lldb) in the error log. If I then run it again (without closing the simulator) it launches correctly. And if I do the same again it crashes. So it seems to be every second time. It works when using a iOS device and I have a college with the exact same project who doesn

Setting breakpoint at NSKVODeallocateBreak

老子叫甜甜 提交于 2019-11-27 16:33:29
问题 I am playing around with the map kit and I created an annotation. I am trying to find my bug due to this error: An instance 0x1b7ac0 of class AddressAnnotation was deallocated while key value observers were still registered with it. Observation info was leaked, and may even become mistakenly attached to some other object. Set a breakpoint on NSKVODeallocateBreak to stop here in the debugger. Here's the current observation info: I'm not sure where that NSKVODeallocateBreak to set a breakpoint

Weird error message in Xcode 4.3 with LLDB

↘锁芯ラ 提交于 2019-11-27 15:17:11
I am currently writing an iOS app with Xcode 4.3.2. In most parts of my code, debugging with LLDB works just fine. However at some point I am getting a strange message while stepping through my code. When I hover over an iVar, it says Error [IRForTarget]: Couldn't find Objective-C indirect ivar symbol OBJC_IVAR_$_MyFancyClass.iVar instead of showing me the value. However, in the Variables View , I can see it just fine. Until I'm selecting Print Description of ... that is, because then, Xcode crashes... When I use GDB, the hovering works but the type and values of the variable are wrong. I

lldb fails to print variable values with “error: reference to 'id' is ambiguous”

拈花ヽ惹草 提交于 2019-11-27 13:25:28
问题 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:

How to debug EXC_BAD_ACCESS bug

筅森魡賤 提交于 2019-11-27 12:50:28
问题 I received an error EXC_BAD_ACCESS code=2 at0xb0987654 I am wondering how to print out the value at 0xb0987654? 回答1: 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,

Xcode - Error creating LLDB target

吃可爱长大的小学妹 提交于 2019-11-27 11:45:36
I'm getting this error whenever I build in XCode 6 beta 4. It seems to be making my app insanely slow. Warning: Error creating LLDB target at path '/***/***/***/***.app'- using an empty LLDB target which can cause slow memory reads from remote devices. What exactly does this mean and how do I fix it? Thanks in advance! khanhlvg Did you use Architectures=$(ARCHS_STANDARD_32_BIT) and run your app on a 64 bit device? (iPhone 5S or iPhone 5S simulator) Apple seems to be stricter with apps which don't support 64bit. So if there is no specific reason, I think it's better to include arm64 in your