Debuggers are back in the spotlight with a recent post from Kasia. She likes debuggers, so do I.
I have already expressed my views here and here on the importance of debuggers and my philosophy is quite simple:
No matter how productive you are with your current tools, I guarantee you will be more productive with an IDE and with a debugger.
I am pretty good with emacs and vi, with pinpointing potential bug areas by just reading code or quickly reading reams of output on a console, but at the end of the day, I just get things done faster if I add my IDE and a debugger to my arsenal of tools. Ignoring this simple common sense is like being a caveman saying that he’s okay without fire.
The point of this entry is not to revive this debate (let’s leave cavemen into their caves) but to ponder the following question: why is there almost no information on how to use a debugger wisely? I don’t mean the user manual telling you how to set a breakpoint and how to single-step through code. I mean a "good practice" guide.
As far as I know, this is not taught in school and hardly broached in books and I wonder why. Is it because debuggers vary widely in scope and functionalities?
I don’t believe this statement is true any more: these days, debuggers have converged toward a very similar set of functionalities and except for a few innovations such as back-in-time debugging, you can reasonably expect your debugger to offer the same functions, regardless of the language or the operating system you are debugging in.
I would love to see a central place where all debugger tips and practices can be found, I’m sure there is a wealth of information waiting to be uncovered out there.
I’ll start with a few tips of my own.
Run method till it exits
Sometimes, you accidentally step into a method you didn’t mean to investigate, typically a library method. You want to "get out" of this method so you can resume the debugging of the method you are really interested in. You do this in Eclipse with the Step return button:
Press it and the current method will be run until it exits and the current frame is popped, taking you back to where the call was made.
Using conditional breakpoints.
I cannot overstate how important conditional breakpoints are. Unless you are working on a very simple piece of code, the bug you are trying to find or the code you are trying to test will probably not be exercised right away, or it will be run several times without the parameters you are expecting. The only way to get there faster is to type in entire expressions in your conditional breakpoint text box.
Using break conditions for println
As I stated in the link above, I’m not a big fan of "println debugging", which is antiquated and actually quite dangerous at times. That being said, a bug sometimes happens after a certain number of iterations which cannot be easily captured by a conditional breakpoint (see below). Or maybe, you just want to have some information about the state of the program displayed on stdout so that when you hit your breakpoint, the console contains some context information.
How could you do this without inserting println’s in your code?
Simple : use a breakpoint expression that will do this println for you.
For example, the expression above could simple be replaced with "System.out.println(methodName)". Since this expression will never return true, the program will never stop, but it will display the value of methodName throughout the entire execution.
Now, that’s what I call an efficient use of println and since the logic is contained in the debugger and not your code, no risk of shipping with it.
Of course, you don’t have to limit this to just println, you could just as easily modify existing variables or do some other crazy stuff…
How about you? Any hot tips to share about your relationship with your debugger?
#1 by Emmanuel Pirsch on October 21, 2004 - 12:07 pm
This is a really nice post! Debugger are really useful and it’s a shame that only a small number of people use them.
The trick on outputting stuff using conditional breakpoints is really a good idea! I often the “watch” feature but you do have to stop at a breakpoint to actually look at it. This tricks will make watching variable a lot simpler and allow for faster debugging.
I’m not sure that doing crazy stuff is really a good idea (like using a JOptionPane to input the value if some condition is filled : stuff= (stuff == null ? stuff= JOptionPane.showInputDialog(“New Value Please”) : stuff) ).
Emmanuel.
#2 by Marc Logemann on October 21, 2004 - 1:57 pm
IDEA offers you many conditional expression and a log expression in the lower left corner (see http://www.logemann.org/divs/greatDebuggerStuff.gif). This way you dont need put println() in your code. I do it nevertheless sometimes, but when doing this, i created a template which looks like this (triggered by “soutv” + TAB):
System.out.println(“*MLDBG: $EXPR_COPY$ = ” + $EXPR$); //todo remove me
The variables get replaced depending on the context and the //todo is a special marker. All todo markers can be viewed in an IDEA window, this way you easily know where you have debug println()’s in your code.
But its really weird that noone ever written something about debugging best practices. I mean more than just a few lines.
marc
#3 by Cedric on October 21, 2004 - 2:01 pm
I always call my logging methods “ppp” so they can be easily grepped, and they always include the class name:
static void ppp(String s) {
System.out.println(“[Account] ” + s);
}
#4 by Hani Suleiman on October 21, 2004 - 2:01 pm
I actually shove a lot of my println’s into a debugger conditional.
Debuggers that allow you to evaluate code in the current frame will actually be much faster than using a println, because you can just evaluate all the things you’d want to print, and immediately act on the info by doing more evaluatings.
Even more fun is changing the value of a variable in a stack frame. Lets’s say you expect x to be “foo”, but for some reason it’s null, you don’t really want to fix that right now but want to get back to it once you verify that when x is “foo”, the rest of the code behaves well. Easy! Just set a breakpoint where you want x to be “foo”. and assign it a value when the breakpoint is hit.
With system.out.println, I find myself fixing one bug at a time, with a debugger, during the same run instance I’ll often fix 3-4, given the powerful combination of hot-deploy and breakpoint magic.
#5 by Greg Hinkle on October 21, 2004 - 3:04 pm
I’m a huge debugger fan as well. What has made debuggers even more powerful for me is context sensitive completion. For example, when creating breakpoint log messages in IntelliJ, the dialog includes the full editor auto-complete for the location of that breakpoint. Even if you are stuck in the mode of printlns for debugging, at least use breakpoint logs so that you don’t have to remember to remove them (and you don’t have to recompile and deploy to add/alter them).
I also love that while I’m stepping through, the watch creation also has auto-complete. And altering stack variables… I use that for negative testing of my code.
#6 by Nils Winkler on October 22, 2004 - 4:10 am
Another great feature are Exception Breakpoints. In Eclipse, you can set a breakpoint on any Exception class and can specify whether you want to trigger it on handled or unhandled exceptions.
So if you know there’s an Exception being thrown somewhere deep in your code, but don’t know under which exact condition, just put a breakpoint on that exception and start your application in debug mode. When the exception is thrown, the program will stop and you can see the actual context. Works great for runtime exceptions like NPE and the like.
#7 by Jean-Baptiste Nizet on October 22, 2004 - 7:17 am
Here’s something that most of you certainly know already, but that I only discovered today (how stupid I feel!).
When you have multiple method calls in a single line of code, you may put the cursor on the method you’re interested in and hit CTRL-F5 in Eclipse to step into this method.
For example, if you have
doSomething(foo.getBar(), baz.blah(), xyz());
and you’re interested into stepping into doSomething(), put your cursor on doSomething and hit CTRL-F5. Hitting F5 (step into) will step into foo.getBar().
#8 by Mark on October 22, 2004 - 8:36 am
For debugging in Eclipse – Bugdel
http://www.csg.is.titech.ac.jp/~usui/bugdel/index-e.shtml
Check out the demos.
What you think?
#9 by Justin on October 22, 2004 - 11:09 am
No matter how productive you are with your current tools, I guarantee you will be more productive with an IDE and with a debugger.
Amen to that! I was using emacs for a long time and moving to Eclipse was pure heaven. I am far more productive now. I don’t even know why people even try with ancient editors. BTW, My favorite feature of the Eclipse debugger is the ability to go back to the beginning of the method and run it over. Without this feature it would be take a lot longer to run through a bunch of different test iterations.
#10 by Pete on October 22, 2004 - 12:02 pm
IntelliJ debugger lets you stop when a field in a class has been modified. This is quite helpful when you are debugging someone elses code who likes to use static fields and you are not sure where it’s being modified.
#11 by Suprakash Das on October 22, 2004 - 12:32 pm
Excellent point Cedric! I cannot agree with you more.
Another feature that most of you probably already know about and that I’ve found very useful in the past… From the Help for the Eclipse Platform – “When stepping through your code, you might occasionally step too far, or step over a line you meant to step into. Rather than restarting your debug session, you can use the Drop to Frame action to quickly go back to the beginning of a method. Select the stack frame corresponding to the Java method you wish to restart, and select Drop to Frame from Debug view toolbar or the stack frame’s context menu. The current instruction pointer will be reset to the first executable statement in the method. This works for non-top stack frames as well.”
Related to the “Change variable” post by Hani; are you able to do this in Eclipse? I haven’t been able to figure out a way to set variables that are null to a not-null value or vice versa during debugging even with simple String literals. This has been a major annoyance in the past.
#12 by Rob in NJ on October 22, 2004 - 2:13 pm
Another nice debug feature of eclipse is “Detail Formatters”.
This comes in real handy when clicking on a variable. Eclipse does a toString() on the object, when that does not make too much sense, IE Calendar, use the following Detail Formatter:
if (this != null) {
new java.text.SimpleDateFormat(“MM/dd/yyyy hh:mm:ss a”).format(this.getTime())
}
#13 by Juan Carlos Vergara on October 22, 2004 - 10:26 pm
Don’t forget hot swap in debugging mode mainly to change classes at runtime when takes a long time to reinitiate some containers and the threads monitor to see the call stack in some execution point
#14 by Patrick Schriner on October 23, 2004 - 3:59 am
AspectJ / AJDT can be used for debugging Java programs in Eclipse as well; Especially good for logging.
#15 by a on October 23, 2004 - 11:45 am
This is a tough one, because with Cedric coming out for debugging, I’m happy to continue to not use debuggers and not waste time with them. But with Hani ALSO using them, I’m torn.
For me, I’m faster than most of my co-workers and write fewer bugs, and don’t use a debugger or an IDE, so I’m not really motivated to use on. Empirically, every really good developer I’ve ever known has used vim/emacs and no debugger. Most developers I know who use IDEs and debugger are slower and write more bugs and are generally not as proficient.
A debugger can tell you what the value of something is at a given point in time, but it says nothing about the data flow, which is what you need to examine when debugging. Furthermore, print statements don’t tell you much about that either. They also tell you what a value is at a given point in time. The way to effectively debug is to understand the data flow: how could value of XX be incorrect? Where is XX’s value changed?. Understanding that is to debug. A debugger doesn’t help any more than print statements.
#16 by Julian on October 23, 2004 - 9:25 pm
I use the debugger about once a week when programming Java in Eclipse. The rest of the time, I can figure out problems by examing the code and program behavior.
My biggest productivity improvement was when I started running my code within Eclipse, which compiles your Java files immediately as you edit them. Avoiding compilation delays is so nice. Plus, everything is set up if a debugger is needed.
#17 by Synomous Howard on October 24, 2004 - 6:30 am
Emacs GUD mode is pretty useful – can anyone point out the advantages of Eclipse over the Emacs GUD mode ?
#18 by Anonymous on October 24, 2004 - 10:37 am
The few times I’ve had to use a conditional breakpoint, the program-slow-down has been so great that I cancelled the run, added an if() statement, recompiled & re-ran.
#19 by Mike Spille on October 24, 2004 - 3:15 pm
I’ve always found debuggers to be more trouble then they’re worth. When I observe people working with debuggers, they seem to always move at a glacial pace. Worse – debugger setups don’t translate across debuggers or developers. As others have stated, a debugger is highly ephemeral in nature.
The speed thing is an issue as well. I can’t believe people are advocating conditional breakpoints. Where I work I actually see a great deal of code written which short circuits great swaths of code or reduces data set size, and this is done explicitly to speed up code under debug, and is useful only for speeding up under debug. I don’t consider this a good thing.
Oh, and Cedric et al, lay off the “println” argument. Professionals don’t advocate println statements, they advocate controllable logging statements, which are a completely different animal. The best thing about them being that you can turn them on, usually dyanmically, if a problem happens outside a convenient debug session e.g. in a QA or possibly even production environment. And my debug logging statements exist for all developers using any tool to switch on. You can’t say that for debuggers – they are individual to the developer and don’t contribute to overall team knowledge or expertise.
Finally – it’s surprising that so many server-side people don’t have problems with timeouts, timing sensitive issues, threading, etc in using a debugger. How many cumulative man-hours (perhaps I should say man-years 🙂 ) do you guys spend hitting endless problems with timeouts and figuring out how to set them artificially high to get your debug sessions to work? How often do you end up blocking or deadlocking your co-workers when you’re stepping through database transactions?
#20 by Anonymous on October 24, 2004 - 7:52 pm
I can’t agree more that IDE and debugger do saves life of a developer. Tell that to my company’s senior “SOFTWARE ENGINEER” who insists that developers uses VI. For GOD SAKE, vi is good if we wanna change bits and pieces of code, but for serious development….. come on DUDE!!!!! And this senior “SOFTWARE ENGINEER” of mine f***king hate IDE’s like eclise, intellij or whatsoever. Whenever I am doing something like “using ctrl click on the name” to jump to the class directly, he would be like “ahhh, you could do that in vi as well”. YEAH! you could but its harder. Once, my colleague was using a debugger and was spoted by him, he would go like “ahh you should be using that at all, it spoils your skills”. I wonder why such person gets promoted to be a “SENIOR SOFTWARE ENGINEER”. LOL.
#21 by Xavier Brouwer on October 25, 2004 - 12:30 am
Try using log4j and scattering DEBUG statements through your program.
You can then use the external log4j properties file to indicate when and how you want debug statements to be outputted. The DEBUG logging level can then be switched off externally to the code when you ship.
#22 by sp on October 25, 2004 - 5:55 am
The debugging is handy when the project is in maintainence mode. More so when the developer who has not developed the feature in first place is responsible for maintainence. Though this is not a desirable condition but never the less not too uncommon. I totally agree with Mike that using debugger should not be a common practice.
#23 by Nico Mommaerts on October 25, 2004 - 7:17 am
“Try using log4j and scattering DEBUG statements through your program.”
Logging is not the same as debugging, although the log level name ‘DEBUG’ may be deceiving. Normally you use logging to have an overview of and monitor the overall status and flow of your system. Debugging is used if you have a small problem while developing and you have need of stepping through your application with additional information (content of values etc). The DEBUG level could have just as easily be named DEVELOPMENT_LEVEL or LOTS_OF_INFO_LEVEL, which helps you while developing.
“Professionals don’t advocate println statements, they advocate controllable logging statements”
Same point
“…you guys spend hitting endless problems with timeouts and figuring out how to set them artificially high to get your debug sessions to work? How often do you end up blocking or deadlocking your co-workers when you’re stepping through database transactions?”
I don’t know about other people, but my debugging sessions don’t take 2 hours 🙂
Just my opinion…
#24 by Kamran Zaidi on October 25, 2004 - 7:48 am
Interesting discussion!
Debuggers helps me a lot, especially when I am working on multi tier project with huge lines of code and want to fix some problem in production in very short time, your know how sensitive sev 1 issues r. I love debugging with IDEs, specially with eclipse.
#25 by Mike Spille on October 25, 2004 - 9:59 am
Nico – I don’t quite get your point on logging levels. I think you’re sort of splitting hairs there. In particular, using something like log4j you can turn on DEBUG for selective packages, so you can tightly target just one small section of your code. Coupling such debug statements with various levels of test, I find a debugger to be superfluous.
“I don’t know about other people, but my debugging sessions don’t take 2 hours :)”.
I’ve seen people stepping through stuff in debuggers for timelines ranging from a couple of minutes to several hours, it depends on their style, their task at hand, and whether they get interrupted or not. A simple phone call in the middle of a debug session can often leave the program hanging in the middle of some time-sensitive piece of code and cause problems. And on many projects I’ve fielded innumerable questions from people on problems related to timeouts and the like coupled with debug sessions. And DB locking is a primary concern because developers often have to share databases. One guy fields a call in the middle of tracing some stuff and half the development staff can be mysteriously locked.
My question remains: for people who advocate debuggers for server side stuff, how do you deal with these issues?
#26 by Anonymous on October 27, 2004 - 9:23 am
Someone asked how to set a null variable to a non-null value in Eclipse. The easiest way to do this is to use the Display view. Just execute an expression like: “myVariable= getNewValue()”.
Since conditional breakpoints have come up a couple times, I should point out that cond. BPs in Eclipse are more powerful than most people realize. Conditions can be either an expression OR a series of statements.
A perfectly valid condition for an Eclipse breakpoint would be:
List[] lists= getLists();
for (int i= 0; i 50) {
return true;
}
}
return false;
#27 by Jared Burns on October 27, 2004 - 9:27 am
Bah. The form really screwed up my condition example (guess that’s what I get for not previewing). Let me try that again.
List[] lists= getLists();
for (int i= 0; i < lists.size(); i++) {
if (lists[i].size() > 50) {
return true;
}
}
return false;
#28 by hoijui on November 1, 2004 - 8:20 am
thanks…
as you say.. i encountered too, that such things dont get thought(teached? 😀 )
i am one of those .. worst case developers…
learne coding bymyself.. and.. only coding (evne that they couldn’t teach us at the IT school i went to)
just now.. after.. about 3 years, i start to realise what i miss… the whole planing thing, how to use debbugers and all that.
will start with this now, wiht help of your tips
..thanks again 🙂
#29 by Nico Mommaerts on November 1, 2004 - 3:35 pm
Mike – About the log4j, I still think there’s a difference between logging and debugging. If I’m debugging a piece of code, it’s because I want to inspect the context I’m in, arguments, variables etc. If I would do this by logging, I’d have to introduce logging everywhere in my code, and dump the value of each and every argument, variable, who knows what else. You just can’t know up front what values you need to see to solve a bug you have.
A debugger also provides you with control of execution of your program, a logger doesn’t. Watching the code execute can give much needed additional insight into the flow control of a piece of code, especially if you haven’t written that code yourself.
About the long debugging sessions, well, if you have seen it yourself, I can’t argue with that of course 🙂 The DB locking you can solve by making each developer work on his own version of the DB, if the project environment allows this.
#30 by Jeff on July 10, 2006 - 10:35 am
Lately my logs have been spammed by http://www.openfos.com The entries will look something like http://www.openfos.com/supply/ with the name of your site or name at the end of the string. There would be dozens of hits a day with the same referal url with multiple user agents. They usually use the following IP’s to spam your logs:
218.153.70.244
221.148.31.116
I don’t mind a hit or two a day, but when you have sometimes 30 hits a day! (The IP’s are also blocked in .htaccess )
The site http://www.openfos.com is registered to a Korean company and e-mail to the IP’s network abuse go unanswered.
I could not find a solution using scripts to prevent the loggin, so I had to go to the server and Apache. Are there solutions to use conditional logging to stop log spamming without going into the main server files?
Thanks!
Jeff
#31 by Mike on August 3, 2006 - 12:29 pm
Jeff,
I don’t know of any way to use a script to keep openfos.com out of your logs. The best things to do is to deny and block the http://www.openfos.com IP’s that your are logging:
218.153.70.244
221.148.31.116
Then use conditional logging (as you are doing) to shunt the openfos entries to a seperate log file that can be manually or deleted on a scheduled basis. I know the deny ip in .htaccess will stop them from getting on your site.
I wish that these companies in places like Korea and China would enforce spam and other web abuse! That would make our life a bit easier.
Good Luck!
Mike
#32 by Mike on August 3, 2006 - 2:55 pm
Jeff,
I forgot to tell you one thing about the conditional logging… Make sure you block the IP’s that belong to openfos.com and then take the openfos IP’s and use them for the shunt to your conditional logging. If you attempt to make a run using the domain openfos.com and use that for the conditional log, they may change their url for the hit. I understand from some lists that openfos web log spamming has changed from using “_” underscores to connect words to “-” hyphens. In any case, the best thing to do is to use the IP’s for openfos to keep the hits out of your logs.
Again,
Good Luck!
#33 by Mike on August 3, 2006 - 2:56 pm
Jeff,
I forgot to tell you one thing about the conditional logging… Make sure you block the IP’s that belong to openfos.com and then take the openfos IP’s and use them for the shunt to your conditional logging. If you attempt to make a run using the domain openfos.com and use that for the conditional log, they may change their url for the hit. I understand from some lists that openfos web log spamming has changed from using “_” underscores to connect words to “-” hyphens. In any case, the best thing to do is to use the IP’s for openfos to keep the hits out of your logs.
Again,
Good Luck!
#34 by Anonymous on August 6, 2006 - 3:40 pm
Here is a script that may keep the spam logs and abuse from your logs. The other thing it does, that is rather funny, is that they will get a blank page if the Korena openfos.com log spammers hit your site. Please note if you add IP’s just put this line and change zeros to the IP number and place it in the script below the first IP in the script:
“000.000.000.000”,
ALSO your pages need to be done in php and this goes at the top off all of your pages. It will also work with any IP’s you want. With some changes it will also work by bot name too.
Depending on how your program logs, this script may also prevent logging of the offensive IP’s or bots.
#35 by Mike on August 6, 2006 - 3:41 pm
Here is a script that may keep the spam logs and abuse from your logs. The other thing it does, that is rather funny, is that they will get a blank page if the Korena openfos.com log spammers hit your site. Please note if you add IP’s just put this line and change zeros to the IP number and place it in the script below the first IP in the script:
“000.000.000.000”,
ALSO your pages need to be done in php and this goes at the top off all of your pages. It will also work with any IP’s you want. With some changes it will also work by bot name too.
Depending on how your program logs, this script may also prevent logging of the offensive IP’s or bots.
#36 by Mike on August 6, 2006 - 3:42 pm
Here is a script that may keep the spam logs and abuse from your logs. The other thing it does, that is rather funny, is that they will get a blank page if the Korena openfos.com log spammers hit your site. Please note if you add IP’s just put this line and change zeros to the IP number and place it in the script below the first IP in the script:
“000.000.000.000”,
ALSO your pages need to be done in php and this goes at the top off all of your pages. It will also work with any IP’s you want. With some changes it will also work by bot name too.
Depending on how your program logs, this script may also prevent logging of the offensive IP’s or bots.
#37 by Mike on August 6, 2006 - 3:44 pm
For some reason, I can’t post the actual script. Sorry! Bur if you look up “php” and “make array” and “exit” you should find the script I’m taking about.
Good luck!
#38 by Millard Stevens on December 25, 2006 - 11:54 am
We have had severe problems with the company called Insight Communications, LLC. They have been hammering our site until we blocked their domain totally. We will now try to keep their hits out of the logs.
E-mails to the company have proved useless so now our legal people are going to “serve” the company for violating posted user agreements and legal notices. They have a real interesting “bot” that uses a normal Microsoft browser string, but looks for robots.txt first. Yea! I real person looking at the site I’m sure.
I become really suspect when I find these companies that have U.S. Government contracts then hammer your site and ignore reports to their abuse departments. It seems like these things are being done with the insightbb’s blessing. But why? Until they become responsible they are blocked from my site.
It brings me to the point, why can’t they develop a database (like that for spam)where these companies agents and IP’s are registered, then webmasters could download it as a master “blocked” list? When companies are blocked and shut out and the people who use their services can’t see anything on the web, perhaps they’d act a lot more responsibly.
Anyhow, that’s what I’d like to see. A master database of abusive bots, IP’s and companies that sponsor them that can be downloaded to a local server to block them from sites.
Can this be done?
#39 by Brent on January 9, 2007 - 10:42 pm
I have been having the openfos problem as well. They get me using the ip 59.10.167.58
It is easy to find them, they always have the same number of hits and visits, unlike a real search engine.
#40 by Mike on January 24, 2007 - 3:12 pm
Brent,
We don’t know about log spam from openfos anymore. We have all of their IP’s and they shunt out of our logs due to the logging configuration. To make a long story short, openfos.com in our logs no longer exists since 2006. We do have the 59.* dumped out of our logs too.
I’m sure Openfos is a great “ambassador” for Korea! LOL!
They are not only log spammers, but they are e-mail spammers too. If any header contains openfos it is “discarded.”
Shame on Korea.net for this garbage!
#41 by Mike on January 26, 2007 - 6:08 pm
Brent,
CORRECTION!
THe log spamming from openfos is though Korea Telecom. You can send an e-mail to [email protected] and wait to see if the stop the log spamming or e-mail spamming from openfos. Ya! Sure! LOL! 🙂
I think APNIC should pull IP’s from abusive companies that allow e-mail and log spamming. Just my opinion.
Our log spamming friends at Korea Telecom:
inetnum: 59.0.0.0 – 59.31.255.255
netname: KORNET
descr: KOREA TELECOM
descr: Network Management Center
country: KR
admin-c: IM76-AP
tech-c: IM76-AP
remarks: ***********************************************
remarks: KRNIC of NIDA is the National Internet Registry
remarks: in Korea under APNIC. If you would like to
remarks: find assignment information in detail
remarks: please refer to the NIDA Whois DB
remarks: http://whois.nida.or.kr/english/index.html
remarks: ***********************************************
status: Allocated Portable
mnt-by: MNT-KRNIC-AP
changed: [email protected] 20040802
changed: [email protected] 20041007
source: APNIC
person: IP Manager
nic-hdl: IM76-AP
e-mail: [email protected]
e-mail: [email protected]
address: Seoul
address: 206, Jungja-Dong, Bundang-Gu, Sungnam, Gyunggi-Do
address: 463-711
phone: +82-2-3674-5708
fax-no: +82-2-747-8701
country: KR
changed: [email protected] 20061009
mnt-by: MNT-KRNIC-AP
source: APNIC
inetnum: 59.10.167.0 – 59.10.167.63
netname: KORNET-INFRA000001-KR
descr: Korea Telecom
country: KR
admin-c: IM05193-KR
tech-c: IM05193-KR
remarks: This IP address space has been allocated to KRNIC.
remarks: For more information, using KRNIC Whois Database
remarks: whois -h whois.nic.or.kr
mnt-by: MNT-KRNIC-AP
remarks: This information has been partially mirrored by APNIC from
remarks: KRNIC. To obtain more specific information, please use the
remarks: KRNIC whois server at whois.krnic.net.
changed: [email protected]
source: KRNIC
#42 by Mike on April 25, 2007 - 4:50 am
This is the silliest thread I have ever had the misfortune of reading. Folks actually arguing *against* debuggers? Please don’t try to pawn yourselves off as software engineers. You aren’t.
I suppose EE’s should stop using line testers and “understand” the flow of electricity in their circuit, eh?
#43 by Mike on April 25, 2007 - 4:51 am
This is the silliest thread I have ever had the misfortune of reading. Folks actually arguing *against* debuggers?
I suppose EE’s should stop using line testers and “understand” the flow of electricity in their circuit, eh?
#44 by Harvinder on March 7, 2008 - 4:31 am
Does anybody know how to make Eclipse move back to some previous line which it has already executed?
Please email if anybody have clue.