This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Do I need to disable NSLog before release Application?
I wonder if someone could help me setup a number of NSLog statements so they print to console when executing in "Debug Mode" but don't print in "Release Mode". I understand I need to add something like DEBUG = 1 to the debug config in Xcode but I can't find where. Also how do I utilise this in my code?
NSLog(#"Print Always");
if(DEBUG) NSLog(#"Print only in debug");
Is there a simple way of doing this?
EDIT_001:
I tried following this but the keys now seem to be only listed under "All Settings", and are presenting as nice names. The one I should be using is GCC_PREPROCESSOR_DEFINITIONS, so I needed to find "Preprocessor Macros", select edit and add DEBUG=1
When you come to use this its simply a case of adding (see below) or some marco to remove the messy #ifdef / #endif tags.
NSLog(#"You always see me?");
#ifdef DEBUG
NSLog(#"Only in DEBUG");
#endif
This is a popular solution:
http://iphoneincubator.com/blog/debugging/the-evolution-of-a-replacement-for-nslog
See comments about using either -DDEBUG=1 or DEBUG=1.
The best solution is not to use NSLog in the first place but instead rely on the debugger.
You can set breakpoints that execute debugger commands to print out anything and you can set the breakpoints to execute the debugger commands but not to stop execution. In practice this works just like NSLog.
By using the debugger to do the logging, you don't have to worry about removing the log statements.
Please have a look at the answers of How to print out the method name and line number and conditionally disable NSLog?. There are some nice macros in there that can be very useful.
I use this:
-(void)debugWinLog
{
NSUserDefaults * defaultsDebug = [NSUserDefaults standardUserDefaults];
theDebugWin = [defaultsDebug boolForKey:#"logger"];
}
Which is called in the awakeFromNib.
It checks the apps plist file for a 1 or 0 for the BOOL entry "logger"
The normal state if off, but when debugging you can then turn it on or off at will in terminal. with the normal defaults write.
The NSlog statments look like:
if ( theDebugWin) {NSLog (#"%#", windowState );}
Related
I'm unable to understand how the mock-debugger extension controls where the next step is.
For example what if I'd like to step 2 lines if I find the word "banana" in my text? Also, I'd like to do something, like "Step In", where I can walk word-by-word - is it possible?
I've seen the this._currentLine = ln; assign, which looks like it controls where the line is, but it's just a simple local variable. How could it ever control anything in the debugger? I can't find any other uses of the _currentLine varbiable where it passes to anything useful API (except for stack tracing, but I don't think it has any relation with the debugger line-control).
The stack trace is the only source for the debugger step visualization. When the debugger gets a notification to pause it requests the current stack trace. The TOS determines where the next execution point will be located. Hence the debug adapter is reponsible to determine this position precisely.
I have a strange problem with the Perl Debugger in EPIC. When I started using it, all worked fine as expected. I would set breakpoints, run a program in debug mode, step through it ... Then, something must have changed but I have no idea what. Now, the debugger or EPIC or Eclipse, I don't know who, sends tons of output to the console window that have nothing to do with my program but with the - seemingly to me - internals of EPIC or the Perl debugger. Here's a little cutout from this output, there is an endless amount of this and the things my program wants to output just get lost.
What is the problem here? I did not find any setting I could change in the preferences, I don't know what to search for, I couldn't find anything in the EPIC docs.
Edit: one thing I remember is I used "use diagnostics;" in another program that belongs to the project, but that is not run or used by the program that is producing this debug output. Maybe it has something to do with that? Can it "get stuck" and be remembered by the debugger later? I know it sounds silly, but that's all I got.
DB<396> ;{
do 'dumpvar_epic.pm' unless defined &dumpvar_epic::dump_lexical_vars;
my $offset = 0;
my $savout = CORE::select($DB::OUT);
dumpvar_epic::dump_lexical_vars($offset);
CORE::select($savout);
};
12|$forceingest|1|1|17|SCALAR(0x40fb5a4)|3|'0'|1|3
4|$lll|1|2|14|REF(0x2739ff4)|37|Log::Log4perl::Logger=HASH(0x41bbe64)|3|...|1|3
9|$reingest|1|1|17|SCALAR(0x40fbf14)|3|'1'|1|3
13|$secondsPause|1|1|17|SCALAR(0x40fb774)|5|'300'|1|5
4|$tdh|1|2|14|REF(0x40ff0dc)|15|GLOB(0x42e7484)|3|...|1|3
12|$transferDir|1|1|17|SCALAR(0x40f9f24)|31|'c:/temp/xml/transfer/probleme'|2|31
8|$usedata|1|1|17|SCALAR(0x40fbf84)|3|'1'|1|3
6|%datah|1|1|15|HASH(0x40f2f8c)|3|...|1|3
5|#data|1|1|16|ARRAY(0x41002ec)|3|...|1|3
13|#transactions|1|1|16|ARRAY(0x40ff07c)|3|...|1|3
14|#transferFiles|1|1|16|ARRAY(0x40ff04c)|3|...|1|3
7|#tx_ref|1|1|16|ARRAY(0x40feffc)|3|...|1|3
DB<397> ;{
do 'dumpvar_epic.pm' unless defined &dumpvar_epic::dump_lexical_vars;
my $offset = 0;
my $varexpr = <<'EOT';
${$h->{'$lll'}}
EOT
my $subref = \&dumpvar_epic::dump_hash_expr;
my $savout = CORE::select($DB::OUT);
my $savbuf = $|;
$| = 0;
$subref->($offset, $varexpr);
$| = $savbuf;
print "";
CORE::select($savout);
};
3|ALL|1|2|14|REF(0x41d9f64)|15|CODE(0x41dbee4)|3|...|1|3
5|DEBUG|1|2|14|REF(0x41d9ba4)|15|CODE(0x41dbee4)|3|...|1|3
5|ERROR|1|2|14|REF(0x41d737c)|15|CODE(0x41d9b34)|3|...|1|3
5|FATAL|1|2|14|REF(0x41d735c)|15|CODE(0x41d9b34)|3|...|1|3
4|INFO|1|2|14|REF(0x41d748c)|15|CODE(0x41d9b34)|3|...|1|3
3|OFF|1|2|14|REF(0x41d9fe4)|15|CODE(0x41d9b34)|3|...|1|3
5|TRACE|1|2|14|REF(0x41d9ee4)|15|CODE(0x41dbee4)|3|...|1|3
4|WARN|1|2|14|REF(0x41d717c)|15|CODE(0x41d9b34)|3|...|1|3
10|additivity|1|1|17|SCALAR(0x41d52bc)|3|'1'|1|3
Never mind. There is indeed a setting for that under Preferences/Perl EPIC/Enable Debugger Console. I enabled that setting previously because of another weird problem with the debugger (threads wouldn't terminate any more and hang there until Eclipse was restarted), which seemed to work. Disabling it stops the unwanted output. Maybe there's something really weird going on with Perl/EPIC on my computer...
I have been googling from last couple of hours for finding that is there any way to clear NSLog output using code or not?
Like we have clrscr() in c. So if we are trying to print something which we want to focus most and there is lots of log printin there we can put that code there and get keep our desire log on top for easy searching. This can be done by putting breakpoint on my NSLog line and than click on clear console. but question is is there a way to achive this programatically?
I found few question on stack overflow but I din't satisfied with answer like this is saying that I can disable log for release mode etc.
Or I can use DLog, ALog or ULog as requirement but my question is different..
Any one can help me in this?
Thanks in advance :)
You can use a conditional breakpoint to simulate it. Define a function like this in your code:
int clear_console()
{
NSLog(#"\n\n\n\n\n\n\n\n");
}
Then, when you want to clear the console just add a breakpoint before the NSLog with this condition:
Condition: 1 > 0
Action: Debugger Command expr (int) clear_console()
Options: Automatically continue after evaluating Check it to skip the pause.
Tested with Xcode 4.3.2 and lldb.
Previous answer:
AFAIK, no, there isn't.
Just in case you're not doing it yet, you can create custom macros to format the output to highlight what you want.
Define macros like this:
#define CLEAR(...) NSLog(#"\n\n\n\n\n\n") /* enough \n to "clear" the console */
#define WTF(...) CLEAR();NSLog(#"!!!!!!!!!!!!!!");NSLog(__VA_ARGS__)
#define TRACE(__message__) NSLog(#">>>>>>>>>>>>>>> %# <<<<<<<<<<<<<<<<<<<", __message__)
Then:
WTF(#"This should't be here object: %#", theObject);
...
TRACE(#"Start Encoding");
...
It's not what you want but it pretty much solves the problem. You'll end up with your own set of macros with custom prefixes easily scannable in the console output.
I'm trying to figure out how to use the log or debug commands in adding actions to a breakpoint. I can't seem to figure it out. For something like this:
double currentZoom = [self getZoomScale];
How do I print out the currentZoom? I tried using log as my action, and then doing
currentZoom: #(double)currentZoom# // this didn't work
currentZoom: #(double)[self getZoomScale]# // also didn't work
Can someone help me out with this and any other info I may need to log information with breakpoints?
And also a simple example for po an object. Does po always po the description (as in you have to have overridden the description method? Thanks.
If you want to print your double with NSLog, add the following line:
NSLog(#"%f", currentZoom);
Now, if you want to use the debugger console...
If you want to print currentZoom in the console, you don't need po. Plain p would be enough.This is, type
p currentZoom
and it's going to show you currentZoom's value. po is for objects. Let's say you wrap currentZoom in an NSNumber.
NSNumber currentZoomNumber = [NSNumber numberWithDouble:currentZoom];
Then, to print the value, you would have to do
po currentZoomNumber
Like i said, po is to print objects, it means print object. So you can use it to print any type of object, from NSStrings and NSNumbers to NSDictionaries and NSManagedObjects.
You can make the breakpoint execute debugger commands.
Open the edit breakpoint pane:
.
Then type a debugger command (selecting "Automatically continue after evaluating" is advised).
To insert some context around the automated debugger commands, you can add another debugger action of type "Log Message". The "Log Message" action is not capable of inspecting variables itself.
NSLog() is probably easier to implement, but requires you to change the code you are debugging.
I do not know how to add actions to a breakpoint. (I am interested in seeing it in any other answers offered)
The gdb syntax for printing objects is
po objectName
The gdb syntax for printing C variables is
print (int) intNum
print (float) floatNum
For assert macros in my iPhone project, I'm looking for a way to programmatically break into the debugger. On Windows (MSVC++), I can use __debugbreak() for this purpose. Invoking this function will stop my program, launch the debugger, and display a callstack of the line that called __debugbreak().
Is there anything similar to __debugbreak() for the iPhone? I've tried Debugger(), but that gives me a linker error.
Thanks,
Claus
edit
Turns out this also works:
#define Debugger() { raise( SIGINT ) ; }
I think it's the same principle.
I use this:
#define Debugger() { kill( getpid(), SIGINT ) ; }
I think it works
in the simulator and on the device.. no assembly required!
A helpful person on Apple's developer forum gave me the tip to use asm("trap") when running on the device and asm("int3") when running on the simulator. This makes the program break into the debugger if you started your programm in debug mode (Option-Command-Y).
(__builtin_trap() also breaks into the debugger, but you can't continue afterwards. assert(false) terminates the program with a message, but doesn't break into the debugger.)
First Add -DDEBUG to OTHER_CFLAGS on your debug target; this will define the DEBUG symbol when building a debug build.
Then add a simple assert macro to your prefix header:
#ifdef DEBUG
#define MyAssert(val) _MyAssert(val)
#else
#define MyAssert(val) do { } while(0)
#endif
Next create a _MyAssert function in a module somewhere:
#ifdef DEBUG
void _MyAssert(int expression)
{
if (expression == 0) {
NSLog(#"Assertion failed!"); // Place breakpoint here
}
}
#endif
Finally create a breakpoint on the NSLog line.
I just set a breakpoint at the place I want to stop. Xcode remembers breakpoints persistently, so any time I run the app with gdb, it'll stop at that point.
If you want to break on assertion failures, a good place to set a breakpoint is on the function objc_exception_throw, in the Objective-C runtime, which is what actually throws an exception. Use the Run > Show > Breakpoints window and double-click the "Double-click for symbol" row, then type the name.
Is there something wrong with the simple assert() macro? Something like
assert(pointerToTest != nil);
will halt your process at that point if the condition is not true. If running under the debugger, you'll be presented with a stack trace of calls that led to the failed assertion. If you want to trigger it every time you hit a certain code path, you could do
assert(false);
I find these assertions extremely useful for verifying that all IBOutlets are non-nil when a window or view is brought up from a NIB.
If you run your program in debug, your app should launch the debugger when it reaches an invalid assertion.
For it to stop, as Jens Alfke tried to say, you need to enable "Stop on Objective-C Exceptions" (under the Run menu).
For more info about debugging vs. releasing and asserts, read http://myok12.wordpress.com/2010/10/10/to-use-or-not-to-use-assertions/
While an ancient thread, found this while researching same topic for Xcode 7. What solved this for me was a feature called "Create Exception Breakpoint..."
Debug > Breakpoints > Create Exception Breakpoint...
This puts a special breakpoint in the Breakpoint Navigator (under View > Navigators > Show Breakpoint Navigator).
This breaks on the actual throw of the exception:
[ exception raise ]
without terminating your code execution. You can just continue if that is how your code is structured.
Double-clicking the break point marker next to "All Exception" lets you adjust where and how the exception break point stops:
Check out conditional breakpoints:
http://www.cocoabuilder.com/archive/message/xcode/2008/10/22/25358