SoylentNews is people
SoylentNews is powered by your submissions, so send in your scoop. Only 16 submissions in the queue.
SoylentNews
What debugging tool do you use the most?
| 7% | 42 votes |
| 39% | 210 votes |
| 13% | 74 votes |
| 7% | 39 votes |
| 7% | 42 votes |
| 5% | 31 votes |
| 10% | 55 votes |
| 6% | 36 votes |
[ Voting Booth | Other Polls | Back Home ]
- Don't complain about lack of options. You've got to pick a few when you do multiple choice. Those are the breaks.
- Feel free to suggest poll ideas if you're feeling creative. I'd strongly suggest reading the past polls first.
- This whole thing is wildly inaccurate. Rounding errors, ballot stuffers, dynamic IPs, firewalls. If you're using these numbers to do anything important, you're insane.
This discussion has been archived.
No new comments can be posted.
What debugging tool do you use the most?
|
Log In/Create an Account
| Top
| 77 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Green light in A.M. for new projects. Red light in P.M. for traffic tickets.
(Score: 1) by acharax on Saturday December 06 2014, @03:41PM
Debugging, reverse-engineering and a plethora of plugins in one. Having used it for close to a decade now I can't imagine using anything else (platform permitting, of course), it all just feels clumsy and slow in comparison. I recall there was a project called EDB that tried to create an equivalent debugger for Linux, but I don't know if that went anywhere (back when I used it it felt grossly unfinished, couldn't even display code in realtime unless execution was paused --- but that was many years ago, so things may've changed).
(Score: 0) by Anonymous Coward on Saturday December 06 2014, @06:00PM
When OllyDbg doesn't 'hit the spot', I open W32DASM 8.93 with the Sharing Violation and Hex Editing patches. If you can wizz around with this tool, you can reverse anything! A similar tool with a slightly different view is HDASM. For hex editing, I like HxD.
(Score: 2) by Jeremiah Cornelius on Sunday December 07 2014, @11:30PM
I use D-Con: https://www.youtube.com/watch?v=P4tJo0K2l1Q [youtube.com]
You're betting on the pantomime horse...
(Score: 3) by tynin on Saturday December 06 2014, @04:07PM
Nice joke whoever put this vote together. I didn't know what it was and went off to find out. Well played.
(Score: 2) by cmn32480 on Saturday December 06 2014, @04:50PM
I had to do the same thing. And it got a belly laugh. And my kids looked at me funny. Which got another belly laugh.
2 Laughs for the price of 1. AWESOME!
"It's a dog eat dog world, and I'm wearing Milkbone underwear" - Norm Peterson
(Score: 2) by jimshatt on Sunday December 07 2014, @01:03AM
(Score: 2) by gallondr00nk on Sunday December 07 2014, @10:43PM
I thought it was a joke referring to DMT [wikipedia.org] until I googled it.
Imagine my disappointment etc.
(Score: 1) by drgibbon on Wednesday December 10 2014, @04:52PM
Oops me too. Although DEET obviously makes more sense since we're talking about debugging :P
Certified Soylent Fresh!
(Score: 2) by Kell on Saturday December 20 2014, @06:33AM
Frankly I would have expected dichlorodiphenyltrichloroethane
Scientists ask questions. Engineers solve problems.
(Score: 0) by Anonymous Coward on Tuesday December 09 2014, @01:19PM
DEET
http://en.wikipedia.org/wiki/DEET [wikipedia.org]
Make me goolge it. shame on you.
(Score: 1) by moondrake on Tuesday December 09 2014, @03:35PM
As I biologist, I do actually use insecticides for "debugging" occasionally (though I prefer dealing with bugs in a more environment friendly way). But DEET is not really suitable for spraying on plants...
(Score: 3, Insightful) by gman003 on Saturday December 06 2014, @11:04PM
When writing C/C++, I usually use the actual debugging tools (gdb or whatever the Visual Studio thing is called, if it has a separate name). I'd probably do the same in Python, if I ever wrote a non-trivial Python program.
When writing in other languages, that lack proper debugging support, I usually use print statements. In PHP in particular, I probably write "var_dump($foo);exit;" more often than any other line of code.
(Score: 3, Informative) by c0lo on Sunday December 07 2014, @01:25AM
I'm using mostly Eclipse as an IDE: its PHP language extension have a good support for xdebug and so I can break/trace the PHP code execution and inspect variables just like for Java or C(++) (via gdb)
https://www.youtube.com/@ProfSteveKeen https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by TheLink on Saturday December 20 2014, @07:24AM
The group I work in writes software in the "business software" domain (asp.net, sharepoint etc) where I believe the low-level efficiency of the code doesn't usually affect overall performance as much as the algorithms used, DB queries and indexes used, architecture used, proper configuration of stuff (load balancers, DBs, web servers) etc.
So for such stuff I often use my logging library which has a context buffer. Even debug level and detailed debugging level logs normally go to the buffer.
Imaginary example (no NDA probs ;) ):
try {
using (X.TransactionScope scope = new X.TransactionScope())
{
log.debug("trying to create user: " + user + " userclass=" + userclass);
userid=createuser(user);
log.debug("assigning groups to inserted user: " + user + "(" + userid + ")");
assigngroups(userid,userclass);
log.debug("assigning additional roles to inserted user: " + user + "(" + userid + ")");
assignroles(userid,userclass);
log.debug("custom provisioning for userid=" + userid)
customuserprovisioning(userid,user,userclass);
log.notice("Successfully created user: " + user + "(" + userid + ")");
scope.complete();
}
} catch (exception ex) {
log.err("while creating user: exception=" + ex2str(ex));
}
If things go well you only see "Successfully created user etc" in the logs.
If stuff happens and there is a log message of error level or worse, you see all the other stuff leading up to the error - because the log library dumps out all the logs in the context buffer, followed by the log error message. So you get the detailed debug level stuff when you need it, and not at other times. You can also set the loglevel to debugall if you want and get all of it all the time, but in production you may not want to do that.
For example (logging at INFO level, context triggering at ERROR level onwards):
2014-12-18 11:07:45.250|###.....|10700|8|NOTICE|starting
2014-12-18 11:07:45.251|##......|10700|8|INFO|info stuff
2014-12-18 11:07:45.258|#####...|10700|8|CONTEXT|2014-12-18 11:07:45.245|10700|8|NOTICE|starting
2014-12-18 11:07:45.259|#####...|10700|8|CONTEXT|2014-12-18 11:07:45.251|10700|8|INFO|info stuff
2014-12-18 11:07:45.259|#####...|10700|8|CONTEXT|2014-12-18 11:07:45.251|10700|8|DEBUG|debug stuff
2014-12-18 11:07:45.259|#####...|10700|8|CONTEXT|2014-12-18 11:07:45.251|10700|8|DEBUG|debug stuff2
2014-12-18 11:07:45.259|#####...|10700|8|CONTEXT|2014-12-18 11:07:45.252|10700|8|DEBUG|debug stuff3
2014-12-18 11:07:45.260|#####...|10700|8|ERROR|an error occurred
2014-12-18 11:07:45.260|###.....|10700|8|NOTICE|ending
Yes it makes performance crappier if you're logging in a tight high performance loop (e.g. instead of a tens of millions ops per X seconds loop, you can only do a million ops per X seconds). But so far I haven't really needed to log in tight loops where it would hurt performance significantly. Not like our customers need to create 10 million users/etc per second. They may want the creation of a user to always take less than 5 seconds but that's not really affected by the logging.
Given the problem domain and this logging stuff I haven't really needed to use the debugger. FWIW I'm definitely not a top programmer or software developer so follow my example at your own risk. WORKSFORME ;).
p.s. the hashes are to make it easier to grep for log messages of a certain level and higher. The other numbers are process id and thread ID. For web stuff you can add IP address and session ID.
(Score: 0) by Anonymous Coward on Wednesday December 24 2014, @04:16AM
The code would be so much more readable if you put the logging statements inside each function instead of before every function call. It's highly unlikely that the actual call to a function will fail and thus instead of logging "Creating user X" before every createuser(X) do: function createuser(x) { log.trace(x); ... }. The log framework should toss in the function name, so no need to include the "Creating user" as you'll know the first date|##|##|#|createuser|... prints the user info.
You could also upgrade to a more modern logging framework. One that lets you do: log.debug("Creating user: %s (%d)", user, userid); so the program doesn't have to do a bunch of wasteful string concats when that logging level is disabled.
(Score: 2) by TheLink on Wednesday December 24 2014, @10:27AM
The code would be so much more readable if you put the logging statements inside each function instead of before every function call.
And the example would be either useless or even less readable. Think a bit more before you post.
One that lets you do: log.debug("Creating user: %s (%d)", user, userid); so the program doesn't have to do a bunch of wasteful string concats when that logging level is disabled.
Read a bit more before you post. You miss the main point of the post and example. With the way I'm doing things, debug level stuff will be processed even in non debug levels. But the debug stuff doesn't appear in the logs till there's an error, in which case the context buffer is written to the logs followed by the error message.
Readers can do the sprintf /format string style stuff if they want. But that's normally slower and more bug ridden than string concats (compare the history of exploitable bugs in sprintf implementations and similar, with the history of exploitable bugs in string concats). So I'm not going to bother using it in my examples, unless there's a good reason to.
(Score: 2) by Subsentient on Sunday December 07 2014, @02:40AM
Most people here use print statements? I hope they were kidding.
I use gdb most myself. I'm not too great with it, but I know enough.
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
(Score: 2, Insightful) by albert on Sunday December 07 2014, @04:47AM
You can display exactly what you need, in exactly the right format.
Debuggers are a pain, and gdb is particularly user-hostile. It has really verbose commands, pain-in-the butt command syntax and dumb defaults for commands like "x", an assembly syntax that doesn't match the vendor's (especially for x86), dumb resistance to disassembling code that isn't in a function, no ability to search memory, inability to follow **both** children of a fork, interference with executable behavior (eats int3, fails to hide rflags.TF), unable to properly disassembly code that far jumps between 32-bit segments and 16-bit or 64-bit segments, still no decent GUI...
(Score: 2) by bzipitidoo on Sunday December 07 2014, @10:42PM
That's right, that's why I use print statements.
I really only find a debugger useful for simple stuff, like halting on the statement that caused a segfault, setting a breakpoint just before that line, then running the program so I can inspect the variables. When the data is complicated, it may not be in a form that the debugger can display. I usually have to write a function to display the data in ways the debugger can't. For example, if writing an encryption scheme, displaying encrypted data may not be much help, need to decrypt the data to make sense of it.
Lot of languages don't have good debugging support anyway.
(Score: 2) by ikanreed on Monday December 08 2014, @08:50PM
The only great debugger I've ever used is visual studio's .net debugger.
I'd love to hear of any others that live up to its standard of data interactivity.
(Score: 2) by edIII on Sunday December 14 2014, @09:22AM
You see, this is why I answered users instead of print statements. In a way similar to you, I can engineer specific pain in the user, and with much training, you can listen to their pain. For me rejoicing comes first, but I do actually learn something from the whole ordeal so that I can bring different pain the next time. That's what distinguishes me from an amateur.
Technically, lunchtime is at any moment. It's just a wave function.
(Score: 0) by Anonymous Coward on Sunday December 14 2014, @12:06AM
still no decent GUI...
Try cgdb - nearly back to the functionality of Turbo Pascal 2.0
(Score: 1) by CirclesInSand on Sunday December 14 2014, @09:51PM
...a pain...user-hostile...verbose...pain-in-the butt...dumb defaults...doesn't match the vendor...dumb resistance...no ability to...inability to follow...fails...unable to properly...no decent GUI...
Oh! So it's basically an average Linux program. After I figure out how to download it, compile/install it, and find where they hid the executable on one of my many necessary partitions, I'll be sure to give it a try.
(Score: 0) by Anonymous Coward on Monday December 15 2014, @06:51PM
Linux is a kernel my dear.
(Score: 2) by Snotnose on Sunday December 07 2014, @05:15PM
At my last job I did bring-up for new ASICs. As they were new there was no debugger. I typically printf'd to logs in memory, when it crashed I re-initialized the memory controller and looked at the memory (it was a JTAG debugger). I also used scopes and logic analyzers a lot.
You can call me antisocial. Just don't call me.
(Score: 0) by Anonymous Coward on Monday December 08 2014, @05:48AM
Nice. While I haven't worked on an actual ASIC, I do a lot of work with FPGAs. I also often don't have gdb available, but usually do have at least some sort of bytestream output for whatever processor(s) (physical or IP core) I'm using. So, "me too" on the print statements.
(Score: 3, Informative) by Snotnose on Tuesday December 09 2014, @06:40AM
I don't actually use printf's, they're too slow and mess up my real time requirements. I've got an array of bytes, every once in a while I'll write a checkpoint to the array and possibly some data values. So foo() might get 0x1x, bar() 0x2x, blatz() 0x3x, etc. In foo I'll write 0x10, 0x11, 0x12, etc as the function progresses.
Some systems have I/O pins that are both easy to write to and to hang a logic analyzer off of. In that case I replace the array with writes to the I/O.
It's remarkably effective. I'm guessing the JS and PHP types don't have a clue what we're talking about :)
You can call me antisocial. Just don't call me.
(Score: 0) by Anonymous Coward on Sunday December 14 2014, @03:28AM
I have done the same thing. In many embedded environments the debug tools either do not exist yet or will never exist. So you end up printf'ing your way thru it. It sucks ass. I usually end up porting it to an environment that DOES have proper debugging support then trying to reproduce the bug there.
I also use select/print in sql type environments quite a bit. You do not always have the correct rights to trace thru stored procedures and it is easier to just print it than to prostrate yourself in front of the dba...
After going thru that using a real debugger feels like cheating :)
(Score: 1) by CirclesInSand on Sunday December 14 2014, @09:46PM
Psssssssh. If you have a console to write debug statements to, you call that embedded programming? Real embedded programmers are lucky to have a single pin to toggle to send the outside world information. Uphill both ways, in the snow, barefoot, none of this console output and emulator stuff kids have nowadays.
(Score: 2) by maxwell demon on Sunday December 07 2014, @07:39PM
Well, if you tell me how I can debug Mathematica code with gdb, I might give it a try.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by isostatic on Monday December 08 2014, @12:07PM
If I'm writing perl, I use "perl -d"
If I'm writing java, I use eclipse
If I'm writing PHP, I shoot myself
None of those were an option, and out of all the options I use:
* gdb: never. I don't write C for starters, and while I'm sure it can debug other languages, there are better options
* print statements: I use this occasionally, especially on perl cgi scripts
* log files: I use these more, especially in java
* oscilloscope: I haven't used one for several years
* users: I use these a lot to find bugs, they're far better than "QA", however isolating where the bug is (usually OSI layer 8) relies on the log files they are generating unknowingly
* N,N-Diethyl-meta-toluamide, I rarely use this, even when I travel to tropical countries, as I tend to stay in air conditioned environments
* I don't make mistakes so don't need to debug, I am perfect, but I still need to debug other people's parts of systems
(Score: 2) by forsythe on Tuesday December 09 2014, @03:46AM
If I'm writing java, I use eclipse
Sadly, they recently moved our development area down to a lab in which, for ``security reasons'', the only Eclipse is a hilariously outdated version that doesn't respect 1.7 and can't be upgraded. So the IDE we're supposed to use cannot actually handle the code we've written, and it's not feasible to go back and re-write all those String switches, uncouple those multi-catches, etc. (Red tape: every change must be justified, and the powers that be won't approve anything that doesn't directly pass off a new requirement.)
So in that situation, Eclipse is just a text editor that can auto-highlight keywords, and which occasionally stops your work by throwing up a modal dialog informing you of its failure to auto-complete. It certainly can't run any programs.
Emacs, print statements, and log files are about as good as one can get in that situation. I'd like to add `users' to that, but our lus-- users are the same people who think that there's nothing wrong with the environment. If we're lucky, we'll get a description of what the monitor was showing when the error was noticed. If we're not, we'll just get ``It's so hard to copy logs off these machines that don't have network connections, so I didn't bother and they've since been overwritten.''
Some machines have a full jdk installed by happy chance, however. If we happen to catch a user on the phone at the right time, we can browbeat them into running jstack and getting multi-threaded stack dumps and locking information.
(Score: 0) by Anonymous Coward on Tuesday December 09 2014, @09:55AM
A system that you cant debug with the log output is more or less impossible to support in production. Perhaps we are using the term "debug" differently but almost all the investigation I have done is looking at log files and existing code and during development if I get weird behaviour that I cant understand from the logging my first port of call is to fix that so that if it all goes to crap in prod I stand some chance of understanding it.
Of course there are log levels and all kinds of configuration and whatever to avoid wasting resources on fine grained logging and getting it right is a big part of writing quality code. imho.
(Score: 2) by istartedi on Wednesday December 10 2014, @10:54PM
What's sad about print statements? Sometimes the program will loop 1000 times, and you know
it's breaking somewhere in there. I'm not tap, tap, tapping through any debugger 456 times to
find where the expected output is wrong. I'm dumping that to a text file and grepping it to
find the problem on line 456.
Appended to the end of comments you post. Max: 120 chars.
(Score: 1) by istartedi on Wednesday December 10 2014, @11:02PM
OK, after I hit submit I thought "they'll probably suggest using
a watch in the debugger". Assuming I know the steps to do that,
it could be different depending on the debugger. Also, the language
may not have that kind of debugging tool available whereas every
language has output statements. You'll already know how to use
the output statement. You may or may not know or trust the watch
procedure in the debugger, and I imagine that gets hairy when the
problem is more than just watching for an expected value. What
do you do in GDB to watch for X==0.5*y? That's not rhetorical. I don't know.
I've never had to know, because output statements are sort of a universal
given, regardless of language or debugger.
Appended to the end of comments you post. Max: 120 chars.
(Score: 2) by TheRaven on Wednesday December 17 2014, @08:59AM
What do you do in GDB to watch for X==0.5*y?
If you know where X will (or, rather, may) become 0.5*y then a conditional breakpoint (it stops the program, runs the condition code, and resumes if it's false). If you don't but X is a global (or heap-allocated object at a known address), then a conditional watchpoint on that location (program enters the debugger as soon as the value is modified, debugger executes condition code, resumes if the condition isn't met).
I've never had to know, because output statements are sort of a universal given, regardless of language or debugger.
Except that you then need to grep the log and make sure that you've put enough information into the log statements to completely diagnose the problem. The entire point of an interactive debugger is that, once you've hit the condition that is wrong, you can inspect arbitrary parts of the program state and see what is happening and understand why it's wrong (and how to fix it). You can also, with some debuggers, modify the code and program state in situ and see if the problem goes away.
sudo mod me up
(Score: 2) by novak on Friday December 12 2014, @02:55AM
I once debugged a flight computer in a hotel room with three LEDs and an SD card. I'm not sure that the competition still exists, but it was for a rocket competing in NASA's USLI (it performed flawlessly, too).
Seriously though, print statements are very flexible. I use gdb, but I still use print statements depending on what I'm doing. I would have put that as my answer but in all honestly I've been using an O-scope more than any software debugging tools lately.
novak
(Score: 0) by Anonymous Coward on Sunday December 07 2014, @04:33AM
Big "F"ing Hammer
(Score: 1) by Darth Turbogeek on Thursday December 11 2014, @11:11PM
I would have said Big F****** Hammer and Duct Tape.
Coat hanger works as well. And of course WD40
(Score: 2) by DarkMorph on Sunday December 07 2014, @01:21PM
(Score: 3, Insightful) by Thexalon on Sunday December 07 2014, @01:41PM
If I have a complete and proper set of unit tests, than the debugging step amounts to "which tests are failing?"
"Think of how stupid the average person is. Then realize half of 'em are stupider than that." - George Carlin
(Score: 3, Interesting) by Bytram on Sunday December 07 2014, @04:04PM
How to you debug your unit tests? =)
(Score: 2) by Marand on Wednesday December 10 2014, @01:35AM
I really like your line of thinking - that's a great point! But, I have a question:
How to you debug your unit tests? =)
With unit tests for the unit tests! It's unit tests all the way down.
(Score: 2) by isostatic on Monday December 08 2014, @12:00PM
I got involved in a project that had that once. Everything worked well, every line of code had a test against it, and they all passed. They then released the users on it and it died, for several reasons.
Shortly thereafter (when I got involved), unit tests got thrown out the window, and real world tests were brought in. We looked at where the problems were, not where developers thought they were.
Unit tests are great when the inputs and outputs are known. Once you throw users into it, once you throw third parties into it, and once you accept that other areas make mistakes (BA, project management, support, anyone but you), you realise that the people who pay the bills couldn't give a stuff about your unit tests or your internal politics. They want a system that works.
(Score: 2) by Thexalon on Monday December 08 2014, @04:05PM
1. Unit tests are a complement, not a substitute, for a QA team. That's the biggest mistake I've seen organizations make with unit tests. Good QA teams will try putting in all sorts of garbage data to see what the system does with it, which will catch a lot of the scenarios you're talking about.
2. It's actually when problems are reported that you start seeing the real benefits of writing the tests. My first step in debugging something like that is to write up a quick automated test that replicates the problem. Then, using some other debugging tools available in the language (yes, including print statements), narrow it down to a method that failed to handle the case, and write up a unit test that covers that use of that method. Then you make the unit test pass, and (here's the key part) ensure that you didn't break something else that was once working correctly by running your test suite. I have very few rounds of "Fixed bug A, caused bug B" because of this.
3. Why do your users think you can throw garbage data into your system and get good results? You can prevent bad data from causing the system to not function at all, but Garbage-In-Gold-Out is not the way computers work, and anyone who is promising differently is engaging in over-promise under-deliver, which is more often than not how business units of all stripes get into trouble.
"Think of how stupid the average person is. Then realize half of 'em are stupider than that." - George Carlin
(Score: 2) by isostatic on Monday December 08 2014, @05:43PM
Unit tests are sometimes useful, yes, however
If I have a complete and proper set of unit tests, than the debugging step amounts to "which tests are failing?"
is wrong, as your system can be broken even though all your unit tests are fine.
anyone who is promising differently is engaging in over-promise under-deliver
Yes, well that's often a big problem, but I'm more concerned with the butterfly effect - a slow disk drive in a server somewhere causes a timeout which causes a chain reaction through various systems that eventually in your rock solid unit tested code is reported as a timeout to the user. Doesn't help them at all.
(Score: 1) by arthurdent on Wednesday December 10 2014, @02:40AM
The point is that if your unit tests are fine and your system is broken, your next step should be to write a unit test to duplicate the brokenness and add it to the test suite, fix the problem, and from now on you'll be automatically notified if it breaks in the same way again. No, it doesn't fix everything, but the earlier you can find an fix a bug, the less money it costs you (and the company).
(Score: 0) by Anonymous Coward on Wednesday December 10 2014, @11:03AM
What you describe here is not an unit test, but a regression test.
(Score: 0) by Anonymous Coward on Saturday December 20 2014, @06:21AM
Say you have thousands of features, there can be many ways to abuse/use each of those features. Add combinations and sequences in usage of those features, and how many tests are you going to have? Stuff like Microsoft Excel, Firefox etc can run code.
Regression tests can be a good idea (to make sure important fixed bugs are not reintroduced). And some unit testing is good. But if you're thinking about having a _complete_ set of tests, you're writing something trivial or you're clueless or you're a PHB seizing an opportunity to expand your department (and salary).
(Score: 2) by Wootery on Monday December 22 2014, @02:06AM
In my opinion for a complicated enough system, it's near impossible to write a _complete_ and proper set of unit tests for it.
That's not so much a matter of opinion, as a matter of computer scientific fact, and software engineering reality.
It's the most important reason the field of formal methods exists.
(Score: 2) by TheRaven on Wednesday December 17 2014, @09:02AM
sudo mod me up
(Score: 1) by quixote on Sunday December 07 2014, @03:30PM
Now what?
It's not much of a tool, and it doesn't work too well, but it's the only one I've got.
(Score: 3, Insightful) by hash14 on Monday December 08 2014, @03:21AM
Lately I've been coding in Java, so using Java's debugger. Java, C and Python all have debuggers which are just fine for my purposes, and usually faster than print statements, which can take a fair bit of effort to format properly, put in the right place, find the right data/function that's corrupt, etc.
On that topic, Python has quite a lovely debugger. My "d register in vim is always set to: 'import pdb; pdb.set_trace()' which makes it dead simple to insert a breakpoint instead of having to mess around in a GUI (java - never use a CLI java debugger) or recompile, reload an executable and reload all previous breakpoints (gdb - there must be a better way to do this, but I haven't taken the time to learn how to do it). On top of that, it's quite simple to test runnable Python code straight from the CLI debugger (possible in Java and gdb as well, but less elegant). Sometimes I even write code in the debugger itself and then paste it back into my working source code. That's how pleasant I find the Python debugger.
So as far as debugging tools go, I'd say Python is the best and Java is close behind. But in C/C++, it can be quite a pain. Best strategy there is quite simply to test, test and test.
(Score: 2) by Wootery on Monday December 22 2014, @02:02AM
Which C/C++ debugger are you thinking of? Visual Studio does a pretty good job.
(Score: 2) by hash14 on Wednesday December 24 2014, @08:44PM
Never used Visual Studio. I was referring to gdb. I find it annoying having to reload the full state of the debugger every time I restart it. I'm sure there's a way to automate it - I hear that you can script the input into it - but I haven't taken the time to learn it yet.
(Score: 3, Insightful) by TheRaven on Monday December 08 2014, @01:13PM
Odd for the poll to list gdb, rather than something more generic. I'll use lldb in preference to gdb where it's available for C/C++, but lots of language have debuggers that make more sense than either, often integrated into the runtime.
Print-based debugging is really the simplest form of trace-based debugging. Unless your platform supports userspace dtrace probes, it's probably the best you can do if your bugs have some temporal properties.
sudo mod me up
(Score: 2) by bart9h on Monday December 08 2014, @02:08PM
Not actually what I use the most (that would be print, gdb, valgrind, in that order), but it should be mentioned. For the most elusive memory bugs, valgrind is a good tool.
(Score: 2) by Marneus68 on Monday December 08 2014, @02:59PM
I know it's not debugging per say, but having the tests validating my work is usually enough to see the side effects and bugs incorporated by a recent change.
ie: If you spend more time writing tests, you'll spend less time debugging.
(Score: 2) by turgid on Monday December 08 2014, @08:18PM
Absolutely. If you write test-first, and do it thoroughly, you'll very rarely have to do any other debugging. As you alluded to when you mentioned bugs introduced by recent changes, having unit tests helps you to understand the code more quickly when you come back to it after weeks or months away.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Monday December 15 2014, @04:49AM
It's "per se", for fuck's sake.
(Score: 1) by boltronics on Tuesday December 09 2014, @01:55AM
Depends on what I'm doing, but I do a lot of shell scripting.
set -x
It's GNU/Linux dammit!
(Score: 2) by Appalbarry on Tuesday December 09 2014, @04:50AM
Actually, we have more problems with ticks around here, so the Tick Twister [ticktwister.com] is our debugging tool of choice.
(Score: 0) by Anonymous Coward on Tuesday December 09 2014, @01:17PM
Thank you.
(Score: 0) by Anonymous Coward on Tuesday December 09 2014, @12:20PM
Here in the gaming industry we just wave all bugs, as long as it compiles it's good enough to go gold.
(Score: 1) by dltaylor on Wednesday December 10 2014, @06:27AM
Loved the big HP when working on an embedded PPC 603. It tied into the source code and told me what the chip was really doing. I could export the X display to my Sun development box (up yours, Wayland) and have the traces and development tools on the same display. In embedded work, a JTAG does much the same thing. I've used logic analyzers, though, clear back to the days when I worked on 6502s. Given just a few channels, I could always have a bit of debug code to trace flow (write Nx to a trigger location), or, with a few more, capture the address and data buses without disturbing timing.
(Score: 3, Informative) by microtodd on Wednesday December 10 2014, @06:07PM
I have this quote in my "fortune" file. One of my favorites.
The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.
– Brian Kernighan
I very, very, very frequently use Data::Dump.
(Score: 2) by E_NOENT on Friday December 12 2014, @01:56PM
+1 for Data::Dumper
You can learn a LOT from:
print Dump($whatever)
I'm not in the business... I *am* the business.
(Score: 0) by Anonymous Coward on Thursday December 11 2014, @12:33PM
This is an entertaining and informative video lecture by Matthew Garrett [wikipedia.org]. Systematically working down from the most common tools and methods all the way to the most obscure, he drills right down to the finest possible detail of debugging on a Linux system. It's a really great video:
Reverse engineering vendor firmware drivers for little fun and no profit - linux.conf.au 2014 [youtube.com]
(Score: 2) by mtrycz on Sunday December 14 2014, @10:26PM
Well worth it. Thanks.
In capitalist America, ads view YOU!
(Score: 0) by Anonymous Coward on Thursday December 11 2014, @08:41PM
At this moment, on this page, my browser is showing this title: SoylentNews Poll | What do you fear the most? ... - Pale Moon
(Score: 0) by Anonymous Coward on Tuesday December 23 2014, @11:47PM
I guess the poll maker most of all fear bugs?
About debugging: whatever that is builtin into the IDE, we don't live in the stoneage anymore, right?
(And yeah it is about time I try palemoon webbrowser)
(Score: 1) by zzw30 on Friday December 12 2014, @04:18PM
I use python's logging because I'm an FNG and I've never really been exposed to proper debugging. The company uses QA-by-users :(
(Score: 2) by isostatic on Monday December 15 2014, @06:15PM
Is there a business case to spend a few hundred thousand dollars a year on a QA team? Is your code bad enough that it causes thousands of dollars a month worth of damage when it gets released?
(Score: 2) by pnkwarhall on Friday December 12 2014, @11:38PM
Print statements - 'cuz I'm a shitty programmer.
Lift Yr Skinny Fists Like Antennas to Heaven
(Score: 0) by Anonymous Coward on Sunday December 14 2014, @02:11AM
This is Windows calling. Your computer have virus.
(Score: 1) by h on Sunday December 21 2014, @01:28AM
(Score: 0) by Anonymous Coward on Monday December 22 2014, @11:06AM
Since I begun programming Clojure, REPL has replaced all debugging tools. Usually I do not need to do anything else than testing the function I suspect (wrapped by pprint, if needed) and I will find the error according to output.