I was having some problems with memory (exc-bad-access) in Objective-C, XCode, for iPhone, so I searched a little bit and found about the (awesome) NSZombieEnabled. Everyone outhere is just explaining how cool this is ... but it doesn't work for me :/
I followed the following 'tutorial': http://www.cocoadev.com/index.pl?DebuggingAutorelease
I double clicked on the executable under the executable tab (left panel) and I added NSZombieEnabled=YES to the environmental variables
I also added a bunch of other options (like malloc history, some custom ~/.gdbinit that I found on the web, etc) but this didn't solve the problem
So basically when I launch (in debug mode) GDB sais
"Undefined command: "NSZombieEnabled". Try "help".
And it basically stops (in the status bar it says - error in GDB - terminating).
The problem is most likely in your ~/.gdbinit file in that the error you have provided indicates that gdb was trying -- and failing -- to parse a command.
In .gdbinit, the command should look like:
set env NSZombieEnabled=YES
To help further, you'd need to drop your .gdbinit in the question. However, there is rarely a need to use a .gdbinit file (for all but advanced debugging). I'd suggest deleting it.
For autorelease debugging, use Instruments....
Related
When analysing my code using valgrind (WSL) only output I get is list of problems found by it.
On the contrary in Clion documentation in valgrind section, images show that output (instruction pointer) can be directly interpreted into code line that has triggered it, as shown on the image below.
Whan do I need to do to toggle on this display mode or at least code line which triggered it, I am using CLion 2022.2.4?
I have already tried playing with diffrent flags but I was unable to toggle this view on.
This could be related to this bugzilla item (but not likely).
I tried it with CLion 2022.3.1 on FreeBSD 13.1. It was painful to get a project setup (clion didn't know where clangd or ninja were, and used a load of unrecognized clangd options).
After that no real problems.
I'm fairly certain none of the Valgrind devs uses WSL so the chances of this getting analyzed and fixed are very low.
I'm completely stumped. I've been debugging for over a year and have only had this problem when the Build Configuration was set to Release. I have the Build Configuration set to Debug and I have checked to be sure I am attaching to the correct process and yet I still cannot see the values while stepping through the code. Has anybody else ran into this issue?
Here is a screen shot:
The value is returning, but I am unable to see the values of ANYTHING in this method or any of the other methods and I cannot figure out why.
Thank you for any hints you can give me.
============================== UPDATE ==================================
I've tried to print out the valued and this is the output I receive:
Notice though, that the value in the Variables view is correct for the result, even though I can't print it out. But the other values, like filePath should not be nil.
This is so weird.
============================== UPDATE ==================================
I put the breakpoint on the return statement and still no luck:
This time I see no value for result:
I was facing the same issue, On mouse hover and watch section for every variable it was showing nil value but while NSLog for those variables it was printing correct value.
now it's fixed. Try this
Go to Product menu > Scheme > Edit scheme or ⌘+<
In Run go to Info tab, change the build configuration to "debug".
Hope it will work.
#Lucy, ideally you shouldn't have to run in Release profile when debugging, Release is meant as an App Distribution profile with a small package size and little / no debug symbols.
But if you must debug on Release (e.g. due to Environment, data reasons), make sure you have the Optimization Level set to 'None' for Release.
You can reach the config above through:
1) Project wide settings - affects all Targets
2) Target specific setting - affects a single Target only
Don't forget to switch this back before App Store distribution. Lower Optimization will generate a larger ipk increasing your users' download time - also the potential dSYM generated.
Background
For context, Debug, Adhoc or Release profiles are purely to id different build configurations that XCode ships with. XCode starts projects with a Debug profile with no Optimization (and various other predefined config related to development & debugging), so symbol loading by the interpreter is possible - you're free to tweak this however you wish.
Theoretically able to establish a Release build profile that's identical to Debug.
I do see part of your problem. notice how self is nil?
That means you are in a method call for a de-allocated object. Turn on NSZombies to debug.
see this SO answer for how to enable NSZombie
Given that it is legal to send messages to nil in objective-C, I would suspect that the object is being deallocated as a side effect of calling doesLicenseFileExist, or by another thread.
You may find it helpful to put a breakpoint in IDLicenseCommands -dealloc method.
I had this problem, and turned "Link-Time Optimization" from "Incremental" to "No" and it resolved the debugging issue.
I've come across the below error. This error persists even if I try to use my code on another machine with same version of Xcode 4.2 final. Can any one help?
Console Output
error while killing target (killing anyway): warning: error on line 2184 of "/SourceCache/gdb/gdb-1708/src/gdb/macosx/macosx-nat-inferior.c" in
function "void macosx_kill_inferior_safe()":
(os/kern) failure (0x5x) quit
The debugger is crashing. Crashing debuggers are a world of pain.
Looks like you are using gdb. Try moving to lldb and see if that works around it.
If that doesn't, try nuking your derived data directory as it may be that you have a corrupt symbol that is causing the debugger to crash.
I have no idea what the error is, but googling for the file produces macosx-nat-inferior.c which describes itself as being a part of GDB. So assuming it is the same file as on your computer, then diving in to it may help solve your issue. However that message appears on line 1981 of the file I found .. so I doubt it is the same one as on your computer. But issues with GDB sound weird.
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 why.
This is an artifact of debugging optimized code. When the compiler's optimization is enabled in your build settings, it moves variables between memory and registers as it decides is best. At the point where you're examining the variable in lldb, it may not exist in registers or memory at all -- even though it looks like it should still be available for display.
It's possible it is a shortcoming of the debug information output by the compiler. Sometimes the compiler will copy a variable into a register for its use and only list that register location in the debug information. Later the register is repurposed for other uses; value is still present on the stack but the compiler hasn't told the debugger that the value can be found there.
The only way to really tell whether it's insufficient debug info or if the value genuinely doesn't exist at that particular instruction is to examine the assembly code by hand. As soon as you turn on optimization with the compiler, the source code becomes a weak view into what's actually being executed in any particular order.
Instead of wandering too far into the wacky world of optimized code debugging, I strongly recommend turning off optimization (Optimization Level in your Build Settings) for your build and debugging it that way, if at all possible. If you do need to debug your app with optimization, make sure you're building with the latest Apple LLVM compiler supported by your Xcode -- there is always work being done to improve optimized code debugging and you want to avail yourself of the most up to date tools you can.
The "Address Sanitizer" in the diagnostics seems to make the values of variables unavailable, too.
Schemes > Run > Diagnostics > Address Sanitizer
In Swift, possibly starting with Xcode 9 and still an issue in Xcode 10, this could even come up when code optimization is turned off in the build settings. As #carlos_ms has pointed out here, a temporary solution is to define the variable as mutable, i.e.
Turn
let foo = Bar().string
into
var foo = Bar().string
in order to cause optimization to skip on this variable. Note that this might not work in all instances.
In this case, a good ol' debugPrint() might help you out.
I'm getting a "Compilation exited with code 134" when attempting to use the "LLVM Optimizing Compiler" switch for release iPhone builds, using MonoTouch 4.0.1.
I don't get much information from build output window at all - just:
"Compilation exited with code 134, command:"
MONO_PATH=(snip)/bin/iPhone/Release/LSiOS.app /Developer/MonoTouch/usr/bin/arm-darwin-mono --llvm --aot=mtriple=armv7-darwin,nimt-trampolines=2048,full,static,asmonly,nodebug,llvm-path=/Developer/MonoTouch/LLVM/bin/,outfile=/var/folders/03/033pAAGuHgGkIy4CorbVV++++TI/-Tmp-/tmp38107451.tmp/Newtonsoft.Json.MonoTouch.dll.7.s "(snip)/bin/iPhone/Release/LSiOS.app/Newtonsoft.Json.MonoTouch.dll"
Mono Ahead of Time compiler - compiling assembly (snip)/mscorlib.dll
What is odd is that in earlier command lines, there is a correlation between the DLL mentioned in the arm-darwin-mono command line and what is the compiling, but in this case it says "mscorlib.dll".
Any thoughts?
I have found a few cases (googling and from bugzilla.xamarin.com) where the error code 134 is related to Mono.Linker being too aggressive (removing something that's needed).
This is easy to confirm by turning off the linker, i.e. "Don't link" in Linker Options. If the build works then you can try isolating the assembly where the linker makes a mistake.
E.g. add a "--linkskip=mscorlib" to the mtouch extra parameters and re-enable linking. This will link everything (Link All) or all SDK (Link SDK assemblies) except the assembly you selected (mscorlib in the example). That's only a workaround and a bug report should be filled so the issue can be fixed properly (and get you all the linker advantages).
However be warned that there are other issues sharing the same error code, like:
http://ios.xamarin.com/Documentation/Troubleshoot#Error_134.3a_mtouch_failed_with_the_following_message.3a
YMMV
mtouch does its native builds in parallel so the logs can be confusing, e.g. you can see a bit of assembly X output followed by some assembly Y output.
Reading the full log might help you (or us) to pinpoint the issue.
I was having the exact same problem Scolestock. My app would build fine until I enabled llvm, then it was "Compilation exited with code 134, command" when trying to build the 7s for the app itself.
I'm elated to say that after 2 days of painstakingly whittling my app down to the core problem, I was able to isolate the issue to the usage of embedded dictionaries such as:
Dictionary<enum, Dictionary<enum, value>>
I was able to fix this by defining a class for the embedded dictionary and using that instead:
public class MyDefinition : Dictionary<enum, value>
{
}
...
public Dictionary<enum, MyDefinition>
Not sure if this will help you, but hopefully it'll help some poor soul who decides to use embedded dictionaries and runs into my same problem.