Hot answers tagged debugging
77
By using a debugger. For the most part, this is also what an IDE does behind the scenes -- it just wraps the experience in a GUI.
On Unix, one of the most commonly used debuggers is GNU gdb, which has largely supplanted the earlier Unix debuggers such as dbx.
To get an idea of what debugging looks like / feels like from the command line, you can look at ...
59
Well, it's pretty simple: not all exceptions are bugs (and similarly, not all bugs manifest themselves as exceptions).
As example of an exception that's not a bug, if you're reading a file from a USB drive and someone yanks the drive out of the socket. That's going to raise an exception (in most languages that support exceptions, that is). But it's not a ...
37
A Duck
From http://www.codinghorror.com/blog/2012/07/new-programming-jargon.html:
A feature added for no other reason than to draw management attention and be removed, thus avoiding unnecessary changes in other aspects of the product.
35
It affects the efficiency in a very good way.
I feel that it's used too seldom by developers.
Not only is it good for debugging but it can also give you an insight in profiling.
For example when line stepping you can feel "ahh" this line took a little too long time to execute and you get a feeling for where the bottlenecks in your app are.
33
I can see a DOS programmer fiddling away and crashing the entire OS when he made a mistake.
Yeah, that's pretty much what happened. On most systems that had memory maps, location 0 was marked invalid, so that null pointers could be easily detected, because that was the most common case. But there were lots of other cases, and they caused havoc.
At ...
32
I would say that it is essential to understand every single detail about why some bugs were occurring and why certain changes eliminated those bugs, and it is also common among developers to sometimes get the program working without really knowing the details about why the fix worked!
The art of changing things until a bug disappears, without understanding ...
29
Debugging eats up time since you are executing code a billion times slower than you would in a unit test. Often there is a better tool for the job: microbenchmarks, performance profilers, unit tests, logging, or just reading the code. With a suite of unit tests you can execute dozens of code paths in milliseconds, which would take hours in a debugger.
I ...
27
I used a debugger for several years while I was writing graphics drivers. I had a second computer that ran the debugger against the first one (because the screen in the primary computer wouldn't work when the graphics driver was broken). It was critical to be able to stop the code and step to the point where I hung the hardware so I'd know what was ...
26
I've seen hundreds of bugs that would have been solved faster if someone had written more asserts, and not a single one that would have been solved quicker by writing fewer.
[C]ould [too many asserts] potentially be a bad programming practice, in terms of readability and maintainability[?]
Readability could be a problem, perhaps - although it's been my ...
25
The preferred approach in agile development would be to get them fixed as quickly as possible, by whomever is available. This is simply because the ownership of the code does not fall to any one person, but to the entire developer group. If one individual is consistently causing bugs, that is another issue that needs to be addressed separately.
25
Logging. Add a bunch of logging to the related module, set it to debug and get the user to send you a copy of the log when the error occurs again.
If you can reproduce the error, set your logger to go to the console, and try to reproduce it. Look for anomalies that only occur when the colour is wrong.
Back track. Find all references find any line of code ...
22
Work arounds
As ChrisF suggests, the pragmatic short term solution may be to use the pause and resume trick, but you have to talk to your customers to know what your priorities should be. For example:
If the fault trashes a £1000 part or causes 4 hours of downtime once a week, while the pause-resume fix reduces production by 1%, they will probably prefer ...
22
Back in my day, we didn't have memory protection and all that snazzy business! We used printf to determine where we were in the program, and we liked it!
Though in all seriousness, it usually meant we were just more careful. Where malloc is called, there had to be a free somewhere else in the program, and such checking was rigorous because in the case of ...
21
Does software testing methodology rely on flawed data?
Yes, demonstrably. Examining the Agile Cost of Change Curve shows that part of Kent Beck's work on XP (I'm not sure whether it was part of his motivation or his justification) was to "flatten the curve" of defect costs, based on knowledge of the "exponential" curve that lies behind the Code Complete ...
21
For one, running in debug mode with recording on is very expensive compared to even normal debug mode; it also consumes a lot more memory.
It is easier to decrease the granularity from line level to function call level. For example, the standard debugger in eclipse allows you to "drop to frame," which is essentially a jump back to the start of the function ...
18
Try making the individual tests as small (short) as possible.
This should reduce the chances of creating a bug in the first place. Even if you manage to create one, it's easier to find. Unit tests are supposed to be small and specific, with low tolerance for failure and deviation.
In the end, it's probably just a matter of experience. The more tests you ...
18
The mindset and attitude to debugging is perhaps the most important part, because it determines how effectively you'll fix the error, and what you'll learn from it — if anything.
Classics on software development like The Pragmatic Programmer and Code Complete basically argue for the same approach: every error is an opportunity to learn, almost always ...
18
If you can't debug you're pretty much not a programmer at all, let alone a good one.
Debugging is a real, practical application of not only technical skills but also analysis ability and thought processes. As a result I'd rate it as a far more useful and relevant test than whiteboard or interview questions.
Unless the job you've got involves spending all ...
18
Debug print statements should be taken out; however, if you're needing to add them to debug a production problem then it may be worth considering if you have enough information being put into your logging framework. Information about parameters, error conditions and so on may well be useful later on when the next bug appears. Using a good logging framework ...
18
Usually the actual fixing of the bug is the simplest part. The main problems I tend to have are these:
Getting an accurate bug report
Most bugs are not crash bugs, and users are notoriously unreliable when it comes to reporting exactly what the bug is.
Knowing what the real behavior should be
I often get bug reports when the software behaves as-designed, ...
18
it's not fun at all when you have to make minor changes and wait 30 seconds to 3 minutes to be able to see if they worked or not
That's the real problem here. You feel unproductive when you have to wait so long for feedback, I know the feeling. Perhaps it is possible to fake out more services and create better test tools so you can get immediate ...
17
If you can reproduce the issue 100% of the time, set a break point on the last step (as early as possible). If you walk through the entire call stack, I'm pretty sure you're going to come up to some unexpected values somewhere, or something that should be called but isn't.
Edit:
And if you're sitting at your wit's end trying to fix the bug and posting ...
17
Depending on what you need out of the code why read it all. Searching by the words you need lets you jump to the parts you actually need so you can read smaller chunks.
Most modern IDEs I've used lately let you do some flavor of a project or directory wide search for a given term which allows you to jump between references even if you don't really know ...
16
Time/deadline pressures are one reason.
If you are up against a tight deadline and you've got your boss breathing down your neck (possibly literally!) then doing this and thinking "I'll come back and fix this later" is very tempting and might be the only thing you can do.
Of course the number of times you actually go back and fix it properly are very few ...
16
Start writing tests for the parts you're working on. You can try a workflow that goes something like this:
Write tests for the part you're about to change. This will also help you understand how the existing code behaves.
Refactor code to support testing if needed, but you may want to write non-unit tests if time is short.
Run your tests to make sure ...
16
I think the answer here is going to depend on what your organization and its programmers want to do. If you are in a company with large, complex product offerings used by millions (say, Microsoft, though I have no idea how that company actually works internally), it may be that no one will ever have time to pay attention to the bug that has no steps to ...
16
No
Customer -> "I have this issue"
Developer -> "I can't reproduce it, therefore it doesn't exist"
I'm sorry but that is simply not acceptable. More so it if is a critical part of an application.
Ignoring bugs is a "head in the sand" approach will inevitably lead to a negative situation in the long run.
16
Testing is meant to find defects in the code, or from a different angle, to prove to a suitable level (it can never be 100%) that the program does what it is supposed to do. It can be manual or automated, and it has many different kinds, like unit, integration, system / acceptance, stress, load, soak etc. testing.
Debugging is the process of finding and ...
16
Just my opinion, but I feel that regular, systematic use of a line-level debugger might be the single greatest productivity enhancement practice that a programmer has available. Whether you are jumping into and trying to learn an existing code base or just trying to get your own code working, get thee into the debugger and start Stepping.
You are fortunate, ...
15
One thing that I've seen several open-source projects do is to write up a standard "form" for bug reports, with sections for commonly-needed information.
If you have a bug reporting site or application your customers have access to, see if you can make a blank version of it the default text of the bug description field. Otherwise, put it somewhere they can ...
Only top voted, non community-wiki answers of a minimum length are eligible
