Tag Info

Hot answers tagged

79

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 ...


60

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 ...


60

Is it reasonable to insist on reproducing every defect and debug it before diagnosing and fixing it? You should give it your best effort. I know that sometimes there are conditions and environments that are so complex they can't be reproduced exactly, but you should certainly try if you can. If you never reproduced the bug and saw it for yourself, how ...


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.


36

I really have a hard time seeing where I went wrong The major mistake was that you reinvented the wheel. Instead of using default mecanisms for logging, you invented your own, which displayed the information within the page. A logging framework would rather store logs in log files, letting you to consult those logs later by SSHing to the server. As for ...


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.


34

You want to look at a logging framework, and maybe at a logging facade framework. There are multiple logging frameworks out there, often with overlapping functionalities, so much so that over time many evolved to rely on a common API, or have come to be used through a facade framework to abstract their use and allow them to be swapped in place if needed. ...


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

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.


29

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 ...


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 ...


29

How do they intend to verify that the bug in question was fixed? Do they want to ship untested code to the user and let them figure it out? Any test setup that was never shown to reproduce the error can't be relied upon to show absence of the error. You certainly don't need to reproduce the entire client environment, but you do need enough to reproduce ...


28

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 ...


27

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 ...


25

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 ...


23

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

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 ...


19

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 ...


19

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, ...


19

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 ...


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 ...


17

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 ...


17

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 ...


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 ...



Only top voted, non community-wiki answers of a minimum length are eligible