Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

New & Revolutionary Debugging Techniques?

CmdrTaco posted more than 10 years ago | from the something-to-think-about dept.

Programming 351

An anonymous reader writes "It seems that people are still using print statements to debug programs (Brian Kernighan does!). Besides the ol' traditional debugger, do you know any new debugger that has a revolutionary way to help us inspect the data? (don't answer it with ddd, or any other debugger that got fancy data display), what I mean is a new revolutionary way. I have only found one answer. It seems that Relative Debugging is quite neat and cool."

Sorry! There are no comments related to the filter you selected.

Oh sod (-1)

Anonymous Coward | more than 10 years ago | (#9033493)

Relativity debugs you!

Re:Oh sod (-1, Troll)

Anonymous Coward | more than 10 years ago | (#9033516)

In Soviet Russia...


Exceptions (3, Interesting)

AKAImBatman (238306) | more than 10 years ago | (#9033500)

Java Exceptions *were* a revolution in debugging. Java stack traces tell you the exact line number something went wrong, and the path taken to get there. More often than not, that's plenty of information to track down the bug and fix it. No need to load a debugger.

Re:Exceptions (3, Insightful)

Anonymous Coward | more than 10 years ago | (#9033505)

Sometimes something goes wrong WITHOUT causing an exception. Those are the bugs hard to find.

Better emphasis (2, Insightful)

Futurepower(R) (558542) | more than 10 years ago | (#9033789)

Often something goes wrong with no runtime error. Those bugs are often really, really difficult to find.

Re:Exceptions (3, Insightful)

bdash (598142) | more than 10 years ago | (#9033527)

Java Exceptions *were* a revolution in debugging.

Because everyone knows that Java invented exception handling...

Re:Exceptions (3, Informative)

Delirium Tremens (214596) | more than 10 years ago | (#9033642)

Java invented the dynamic analysis and handling of stack traces [] , not just exceptions.
If you are into dynamic analysis and recovery of exceptions -- that is, self-healing software --, that is a very powerful tool.

Re:Exceptions (3, Informative)

bdash (598142) | more than 10 years ago | (#9033652)

Java invented the dynamic analysis and handling of stack traces, not just exceptions.

Where is your evidence that Java "invented" this? I have seen several other languages that are at least as old as Java that contain this feature, so some facts wouldn't go astray...

Re:Exceptions (1)

mattgreen (701203) | more than 10 years ago | (#9033733)

I fail to see how stack traces are self-healing software. The program still crashes, self-healing implies that it would somehow get around the error and continue execution at some point.

Re:Exceptions (0)

Anonymous Coward | more than 10 years ago | (#9033774)

This has been done for ages in (carrier-grade) embedded system. Walking back the stack and compare the each stack frame with the run-time symbol table is TRIVIAL. I've done that (in C) years ago. that how the debugger work with core-dumps, except that you do that at runtime. Nowaday, you rarely need to do that manually since most modern embedded oses have that facility built-in.

Just look at the ABIs. All of them were designed so that you can walk the stack at run-time. And most of them predate Java for decades.

The only revolutionary thing from Java is its ability to attract a humongous number of (technologically-blind) zealots.

Re:Exceptions (2, Informative)

smallpaul (65919) | more than 10 years ago | (#9033790)

Java invented the dynamic analysis and handling of stack traces, not just exceptions.

Python has the same feature and Python is older than Java. It would take some effort to prove that Python had introspection of stack traces before Java did, but it seems quite likely to me. And it seems even more likely that some variant of Lisp had it long before Python.

Re:Exceptions (1)

bdash (598142) | more than 10 years ago | (#9033818)

A quick look at the Python sources reveals a file named traceback.c [] that contains the "traceback implementation". The earliest revision in Sourceforge's CVS repository is dated Thu Dec 20 15:06:10 1990 UTC [] .

I would be interested to hear when Java developed similar features.

Re: Old news (4, Interesting)

David Byers (50631) | more than 10 years ago | (#9033571)

Back in 1987 the FORTRAN compiler i used generated code that prited the source-code location of all failures, and that feature was old news even then.

Besides, nontrivial bugs don't result in stack traces or crashes. They result in infrequent, hard-to-spot, anomoalies in the output. No amount of Java stack traces will help you find them.

living under a rock? (2, Informative)

hak1du (761835) | more than 10 years ago | (#9033581)

Java Exceptions *were* a revolution in debugging.

Only if you have been living under a rock. Most languages and compilers other than C and C++ have been doing that forever. Even C and C++ allowed you to get a complete backtrace and inspect the complete program state from a core file (software bloat has made more and more people turn off that feature, however).

Re:Exceptions (0)

Anonymous Coward | more than 10 years ago | (#9033617)

What? You're saying every bug produces a crash at precisely the location that the bug occurs?

Re:Exceptions (1)

Morgahastu (522162) | more than 10 years ago | (#9033625)

Perhaps but making your program rely on catching execeptions to handle bugs isn't very good. And adding a bunch of try and catches when you experience a bug to try and find it really does take a long time.

Re:Exceptions (3, Funny)

eyeye (653962) | more than 10 years ago | (#9033637)

Line numbers? What next.. fire?

Re:Exceptions (1)

Tim Browse (9263) | more than 10 years ago | (#9033728)

Heh...that's set me up for the day! Thanks :)

"Get on that teletext!"

Re:Exceptions (1)

smallpaul (65919) | more than 10 years ago | (#9033768)

Python had this feature in around 1992, long before Java was called Java or was public.

hmm (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#9033503)

Relativly first post!

What's New? (1)

ipour (177686) | more than 10 years ago | (#9033507)

Seems like this form of debugging isn't too different from alpha testing. I don't see how this saves any work.

Avoid debugging (5, Insightful)

heironymouscoward (683461) | more than 10 years ago | (#9033508)

You get what's called 'glassnose syndrome' too easily.

Instead concentrate on building software in many small incremental steps so that problems are caught quickly, and on separation of design so that dependencies are rare.

If you can't find a problem, leave it and do something else.

Otherwise, print statements, yes, that's about the right level to debug at.

Re:Avoid debugging (1)

Frank White (515786) | more than 10 years ago | (#9033607)

Your search - "glass nose syndrome" - did not match any documents.

Which is nice... (4, Interesting)

Kjella (173770) | more than 10 years ago | (#9033619)

...unless you happen to have two pieces of software, that each function excellently alone, yet dies a horrible death together, for reasons unknown.

I've got this thing with OpenSSL, Qt and my code right now. On a one-time run, it works fine. When I put it into a program and try to loop it, it crashes on some mysterious and horrible error, sometimes on 2nd pass, sometimes 3rd, 4th pass or more.

All I'm getting from traceback logs are some wierd memory allocation errors in different places, e.g. in Qt code that *never* crashes if I replace the OpenSSL code with dummy code, but has nothing to do with each other. Or in OpenSSL itself, which I hardly think is their fault, if it was that buggy noone would use it. And only if this is put together and looped. Each taken apart, they work perfectly.


Re:Which is nice... (0)

Anonymous Coward | more than 10 years ago | (#9033816)

The reason this is happening is there is something wrong.
You have to find out what's wrong and fix it.

Re:Avoid debugging (1)

TrentL (761772) | more than 10 years ago | (#9033638)

My programs don't have a lot of bugs when they are finished. I think the reason is that I physically cannot code for more than 15 minutes without compiling and running. Obviously, my programs do have bugs that turn up when they're "done". But I catch a helluva lot before that time becuase I test each little bit of functionality as I build it.

Re:Avoid debugging (4, Insightful)

mattgreen (701203) | more than 10 years ago | (#9033705)

Ah, nothing like claiming that your way of approaching something is the only way. A debugger is just a tool. Like any other tool it can be bad if it is misused, and it isn't appropriate for every situation. I find a debugger invaluable for jumping into someone else's code and seeing exactly what is happening step-by-step. Debuggers can be great if you suspect buffer overflows and don't have access to more sophisticated tools that would detect it for you. Just yesterday I used a debugger to modify values in real-time to test code coverage.

Inserting printf statements into the code is probably not logging - usually if you are debugging they are destined for removal anyway. I use a logging system that shows the asynchronous, high-level overview of events being dispatched and then can use the debugger to zero in on the problem very quickly without recompiliation. In addition if a test machine screws up I can remotely debug it.

If you want to throw out debugging because Linus isn't a fan of it, be my guest. But I'm not a fan of wasting time, and injecting print statements into the code plus recompiling is a waste of time and ultimately accomplishes close to the same thing as debugging. Any decent IDE will let you slap a breakpoint down and execute to that point quickly. But I assume someone will come along and tell me that IDEs are for the weak as well.

Re:Avoid debugging (3, Insightful)

jaoswald (63789) | more than 10 years ago | (#9033767)

The main advantage of printfs over IDE/interactive debugging is that you can collect a lot of data in one burst, then look at the text output as a whole.

The tricky part about IDE/interactive debugging is understanding the behavior of loops, for instance. Sure you can put a breakpoint in the loop, and check things everytime, but you quickly find out that the first 99 times are fine, and somewhere after 100 you get into trouble, but you don't quite know where, because after the loop, everything is total chaos. So you have to switch gears; put in some watch condition that still traps too often (because if you knew exactly what to watch for, you would know what the bug was, and would just fix it), and hope that things went wrong, but left enough evidence, when it traps.

Whereas print statements let you combine the best of both worlds: expose the data you care about (what you would examine at breakpoints), but the ability to scan through the text result to find the particular conditions that cause the problem (what you could potentially get from watch conditions).

Re:Avoid debugging (1)

mattgreen (701203) | more than 10 years ago | (#9033793)

You've given me one case where print statements are better than a debugger. OK, that still doesn't prove that debuggers are worthless, as the original poster implied.

Valgrind (4, Interesting)

brejc8 (223089) | more than 10 years ago | (#9033517)

Oh I do love it. My boss had 100% faith in his code claiming that he tests it so much it cant have any bugs. Running it through valgrind showed pages worth of bugs which were only accidently non-fatal.

Re:Valgrind (1)

evvk (247017) | more than 10 years ago | (#9033535)

Yeah, Valgrind is a wonderfull aid.

More of the same (4, Interesting)

poptones (653660) | more than 10 years ago | (#9033518)

How is this "revolutionary?" All you are doing is generating a bunch of test vectors and feeding them to a machine instead of comparing them yourself. You could let programs "create" the test vectors if, as it says, there is another program of similar function to generate the vectors, but what if there isn't one?

All you are doing is replacing human eyes with a computer at the first "filter" process. Instead of having to compare a bunch of values and look for the errors, let the machine point them out to you - grep anyone?

I see nothing reolutionary about this. You still have the DUT making "assertions" - duuuuh can you say "print?"

Re:More of the same (1)

Herschel Cohen (568) | more than 10 years ago | (#9033561)

Let's be fair, assertions are programming logic and if untrue you can exhibit quite a bit without stopping for another print.

Nonetheless, assertion code is not new and I have encountered it in several languages and I know <b>very few</b>. What is more appropriate is what has been pointed out by other, earlier messages: a reference application may not exist.

Print statements work fine for me, too (5, Interesting)

YetAnotherName (168064) | more than 10 years ago | (#9033519)

I haven't used a debugger in years; print statements are the only debugging tool I need.

But bear in mind that almost all of my work these days are in environments where the bugs that traditional debuggers help you find are pretty much impossible to make in the first place (Python, Java, etc.). Instead of tracing data structures through bits of memory and navigating stack frames, you just focus on the application itself. It's kind of refreshing.

Re:Print statements work fine for me, too (1)

littlefoo (704485) | more than 10 years ago | (#9033568)

Using the stack/back-tracing abilities in eg. Python and Java, do avoid many of the times you'd have to fire up a debugger in say, C or C++ - in fact this works fine until the bug is actually in ummm Python for instance, where many of us have spent plenty of time.. Who debugs the debuggers ?

Re:Print statements work fine for me, too (5, Insightful)

Gorobei (127755) | more than 10 years ago | (#9033634)

Print statements are a great tool, especially on large pieces of software maintained/enhanced by many people. Once you've debugged your problem, you just #ifdef out the prints, and check the code back into version control.

When the next poor programmer comes along, trying to fix/find a bug in that code, he a) can #ifdef the prints back on and quickly get debugging output about the important events taking place in his run, and b) read the code and see where the hairy bits are, because they tend to be the sections most heavily littered with debugging print calls.

Fancy debugger IDEs just don't support this preservation of institutional knowledge.

Re:Print statements work fine for me, too (2, Insightful)

Anonymous Coward | more than 10 years ago | (#9033710)

Yeah, it's always tempting to leave your debug printfs in and ifdef them out but I find that has two problems:

1. When reading the code for logic, the print statements can be distracting and take up valuable vertical screen realestate. An algorithm without printfs can usually fit on a single screen. With printfs it may spill over two pages. That can make debugging harder if you need to understand what you're looking at at a conceptual level.

2. Almost invariably I find that a previous person's printfs are almost totally useless because that person was usually debugging a different problem. Thus, enabling old printfs will dump out a whole bunch of information I couldn't possibly care about.

Thus, I make it a point to clear out any debug printfs I was using before I check in my code.

Re:Print statements work fine for me, too (0)

Anonymous Coward | more than 10 years ago | (#9033787)

1. When reading the code for logic, the print statements can be distracting and take up valuable vertical screen realestate. An algorithm without printfs can usually fit on a single screen.

Use an editor with folding capability.

With printfs it may spill over two pages. That can make debugging harder if you need to understand what you're looking at at a conceptual level.

Redirect stdout/stderr to a file. Besides, this sounds like a straw man. There's nothing stopping you from having differently detailed level of debugging output.

Thus, I make it a point to clear out any debug printfs I was using before I check in my code.

Fine, but I hope you document how you tested/debugged the algorithm so another developer can recreate whatever it was that you did.

the problem with print statements... (2, Insightful)

Anonymous Coward | more than 10 years ago | (#9033750) that they don't help in time-dependent situations.
For example, a program in C that uses lots of signals and semaphores could perform differently when print statements are added. This is because print statements take a (relatively) long time to execute. Print statements can affect the bug their supposed to be monitoring.
I had a situation very much like this. One process would fork and exec another, and they would send signals to each other to communicate. But there were a few small bugs that caused one of the processes to occationally miss a signal. When I added the print statements, it slowed the process down enough that it caught the signal. The only way i was able to successfully debug it was with a line-by-line trace with pencil and paper. I don't know if ddd would have helped (but I didn't know about it at the time).

Nothing I've done needs relative debugging (4, Interesting)

DeadSea (69598) | more than 10 years ago | (#9033521)

To use relative debugging, you need a reference implementation that is correct. The only time I have that is when I'm extending an existing implementation with new functionality. In that case I use unit tests with assertions that compare the new and the old implementations.

I suppose this would be useful if you were writing something in a new programming language. You could port your code and run the relative debugger to make sure that both implementations acted the same. In such a situation, that would be great, but such a situation isn't the common case for me.

Re:Nothing I've done needs relative debugging (1)

Bozdune (68800) | more than 10 years ago | (#9033780)

Actually, what you need more than a reference implementation is a set of assertions to test against, i.e. "state" -- the value of various items or datastructures at a given point in time. The problem, of course, is exactly what DeadSea is complaining about. Where's the reference data going to come from? We should all be so lucky to have such data.

I actually think that the problem goes beyond data.

I proposed a thesis at MIT that leveraged a parser generator to build a state machine representing the proper paths of program execution. Basic idea is that each key section of your program emits a token, the tokens are parsed according to a pre-defined grammar, and the parser generator's built-in syntax checking finds at execution time any paths that weren't anticipated.

In other words, if you can write a grammar that describes all execution paths your program ought to take, then a parse error during testing becomes something that's really quite interesting to drill down on. The token stack tells you what happened, the parser knows what state you're in, what production it's reducing, and so forth, so it's easy to track down not only the call stack, which typically has limited context to tell you what's REALLY going on, but also the overall context of where you are and what the hell you're doing.

Since LR parsers are really, really fast, the state tables they generate are small and tight, and tokens are generated at a relatively low frequency, the whole scheme imposes essentially zero overhead on program execution.

Although the faculty member to whom I proposed this was wholly uninterested (Barbara Liskov: "The problem is not control, it is data" -- thanks for the deep insight, Barb), some guy in Canada got his PhD a couple years later with a similar idea. Don't know whether the concept ever found its way into a commercial product, but I would have killed for it a couple of different times in my career, especially for things like driver-level interrupt routines.


Anonymous Coward | more than 10 years ago | (#9033522)

SOUTH (EAST) INDIANS are the vile dark-skinned stinky indians working on an H1 visa. These are those curry munching smelly assholes who steal your holy american jobs.

amongst these TELUGUS, the STINKIEST are the worst.

North, East and West indians arent many and are generally less stinky.

Good idea.. (2, Insightful)

sw155kn1f3 (600118) | more than 10 years ago | (#9033525)

Good idea, but isn't unit testing + standard assertions do the same thing but in more automatic way ?

You feed some data to functions, you expect some sane pre-calculated output from them. Simple yet powerful.

And more important it's automatic. So you can integrate it into build process.

Re:Good idea.. (1, Interesting)

Anonymous Coward | more than 10 years ago | (#9033573)

And more important it's automatic. So you can integrate it into build process.

Part of me thinks that the appeal of debuggers versus unit testing is that a debugger is something mysterious to use and therefore feeds the ego, versus unit tests which are simple to write.

Course the end goal for a programmer is to deliver a workable system, and I think unit tests are the way to get there.

AppSight Debugger (4, Informative)

dominick (550229) | more than 10 years ago | (#9033526)

I am attending a college pursuing my Software Engineering degree and a company called Mutek showed us via weblink a new problem to track software issues. They called it AppSight. It could tell you exactly at which point your program failed. It even showed all the .DLLs your program called, COM objects that were created and even system calls made by the App. Mutek was bought out I believe and is now called Identify Software. You can see more about their technology at: - Dominick

Re:AppSight Debugger (1)

sjwt (161428) | more than 10 years ago | (#9033653)

But did it popup a nice freindly pink window
with a title of "Dont panic" and all that info
in it as well??

As an actual question though,
how customsable is it??

Another cool technique (5, Informative)

Halo1 (136547) | more than 10 years ago | (#9033529)

Debugging backwards in time. See the Omniscient Debugger [] for an implementation in Java. Instead of re-executing the program a thousand times, each time setting breakpoints and watchpoints in different places to get nearer to the root cause of the problem, this debugger completely records all key events and lets you view the complete program state at any point in time.

cool, but not useful (3, Insightful)

hak1du (761835) | more than 10 years ago | (#9033613)

That sounds cool, but it isn't all that useful in practice. Debuggers that support stepping backwards usually end up keeping a lot of state around, which limits them to fairly small, well-defined problems or modules. But the problems where an experienced programmers need a debugger are just the opposite: they involve lots of code and large amounts of data.

Usually, it's best to avoid going back and forth through the code altogether; insert assertions and see which ones fail.

Re:cool, but not useful (5, Interesting)

Halo1 (136547) | more than 10 years ago | (#9033656)

Well, he has used the Omniscient Debugger to debug itself. In a paper published about it at the AADEBUG03 conference, the author writes
In actual experience with the ODB, neither CPU overhead nor memory requirements have proven to be a major stumbling block. Debugging the debugger with itself is not a problem on a 110 MHz SS4 with 128 MB. On a 700 MHz iBook it's a pleasure. All bugs encountered while developing the ODB fit easily into the 500k event limit of the small machine.
I also disagree with your assertion that all situations where experienced programmers need a debugger involve lots of code and large amounts of data. The former is most of the time true, but latter isn't necessarily.

Debugging? (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#9033530)

Pah, I use one of those handheld jobbies. You just wave it over stuff and if it finds bugs it'll go "eeewwwWWWWwww" really loud.

If it's good enough for James Bond, it's good enough for me.

Hey, nice ad! (4, Insightful)

EnglishTim (9662) | more than 10 years ago | (#9033536)

I can't escape the suspicion that the anonymous poster is actually in some way connected to Guardsoft, but let's leave that for now...

I think it's a good idea, but I do wonder how many situations you'll be in where you already have an exisiting program that does everything you want to test against.

Having said, that, I can see how this would help with regression testing - making sure that you've not introduced any new bugs when fixing old ones. But I wonder how much it gives you above a general testing framework anyway...

Re:Hey, nice ad! (5, Insightful)

fishdan (569872) | more than 10 years ago | (#9033643)

I agree with you. I would have rather seen it posted without a reference to guardsoft and have someone mention it. I'm all for advertising on /. -- just not in the form of news.

The fundamental issue here is that people are ALWAYS looking for a way to avoid having to write unit tests. I'm happy with a combination of Intellij and print statements. So far I've never had a situation where I though "the debugger isn't giving me enough information."

I think that one of the reasons I'm happy with the debugging options available to me, is that I write my code so that it can be easily followed in the debugger. That means splitting my declarations and assignments, and other such things that make my code a bit more verbose, but eminently more readable. Lord knows as a child, I loved those complicated boolean switches, and cramming as much line into one line of code as possible. Now that my code is maintained by more people than me, I'm tired of people having ot ask me "what does this do." I used to get angry at them, but now I get angry at myself when that happens. We don't just write code for the users, we write it for our peers. Write code that your sibling developers will be able to follow in a debugger. I know some code is hard to follow, even with a debugger, so I write all my conditions as clearly as possible, name my methods and variables as clearly as I can and refactor reusable code into well named "submethods", so that we can solve "modules".

This is because I want my code to last beyond my employment. Therefore it has to be maintainable by someone other than me. The real test of your code is: can someone ELSE debug it, using whatever the heck tools they want. A fancy debugger is a fine thing, but someday someone is going to have to debug your code with inadequate tools. My rule of them is "Code as if your life depended on someone else being able to fix it"

Aspect-Oriented Programming can help (5, Informative)

cpu_fusion (705735) | more than 10 years ago | (#9033545)

I've found that aspect-oriented programming [] using tools like AspectJ [] (for Java) can be a big help. There are aspect-oriented programming tools for many other languages.

Basically, you can define an aspect to capture points in your program that are of particular note, and then do debug handling at those points. Aspect oriented programming allows you to break out that debug-handling logic into seperate modules, keeping your main sourcecode nice and clean.

Aspect-oriented programming (AOP) has a lot of other uses too. I think in 5 years or so talking about AOP will be as commonplace as talking about OOP. They are orthogonal concepts.

Cheers, Me

Relative debugging, an idea whose time has come (1, Funny)

Red Warrior (637634) | more than 10 years ago | (#9033551)

I have some relatives who demonstrate numerous error conditions.

Re:Relative debugging, an idea whose time has come (1, Offtopic)

Patrik_AKA_RedX (624423) | more than 10 years ago | (#9033620)

Reboot them. Solves quite a lot of the problems. Male relatives can be rebooted with a well aimed kick in the nuts. (source: BOFH)
I'm not sure if there is a way to reboot female relatives. Except perhaps pulling the plug and doing a cold reboot, but I'm not sure if that's legal.

Right... (1, Funny)

Anonymous Coward | more than 10 years ago | (#9033553)

So you already have to have a program that does what your program does in order to check it.

Ever think of deploying that one?

Revolutionary? NO. (3, Interesting)

News for nerds (448130) | more than 10 years ago | (#9033556)

It looks no more than a fancy variation of good old 'assert' macro, or an antecedent [] of unit testing. Why did this anonymous submitter find it 'revolutionary'? What does it have over current debuggers which can be attached to working process or can analyze post-mortem dump?

Old methods best. (4, Insightful)

hegemon17 (702622) | more than 10 years ago | (#9033557)

"Relative debugging" seems to be what people have always been doing. Dump some state and comapre it to an expected state. Most frameworks for regression tests do something like that.

The best debugging method is to have a fast build environment so that you can add one printf, rebuild, reproduce the bug, move the printf to an even better place, rebuild and reproduce, etc. The more you rely on your tools to do the work for you, the less you understand the code and the less you understand the code, the more bugs you will make in the future.

There are no shortcuts to good code.

The use of formal methods? (1)

rahard (624274) | more than 10 years ago | (#9033560)

Would the use of formal methods eliminate(or perhaps lessen) the use of debugging? Is there anybody doing real development with formal methods?

See Formal Methods Virtual Library [] for more info on Formal Methods.

My guess, "real" programmers still use print statements.

... now, i'm trying to printf my Gmail account with mails! ...
-- br

Re:The use of formal methods? (1)

Detritus (11846) | more than 10 years ago | (#9033658)

If you assume that the requirements are correct and that there are no bugs in the compiler, libraries and hardware.

Re:The use of formal methods? (1)

mattgreen (701203) | more than 10 years ago | (#9033757)

What tripe.

Ah yes, those damn errors in hardware are surely remedied by printf! Plus, there's tons of buggy hardware floating around that invalidates formal methods! And whose blasted compiler writers sure aren't very good, we might as well write our own compiler! Who needs mathematical proofs of correctness when we can have printf's strewn everywhere? And I'm sure its completely impossible to use BOTH formal methods and printf's!

.NET (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#9033564)

.NET has kickass debugging capabilities.

Why dont you primitive linsux hippies get out of the stone ages and see what software development is like in the 21st century?


Copyright (c) 2004 Mike Brona, MCSE, MCDST, MS Office Specialist, Well-Respected VB Scripting Guru

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".

Re:.NET (0)

Anonymous Coward | more than 10 years ago | (#9033585)

.NET has kickass debugging capabilities.

You're kind of right, I've never seen any .NET project with serious bugs. Then again, I've never seen any serious .NET project...

Re:.NET (1)

gatkinso (15975) | more than 10 years ago | (#9033602)

I have. Visual Studio for one.

Re:.NET (2, Informative)

gatkinso (15975) | more than 10 years ago | (#9033624)

1) you are correct, VISUAL STUDIO has a great debugger for its products - but that isn't .NET per se. The VC++ debugger is hands down the best in the industry but...

2) gdb will do everthing VCDB does, just not as easily (ok not even remotely as easily)

3) there are guys/gals at my work who write very tight code under gcc - they rarely need a debugger anyway. Their debugging is almost all done at design time

Posts like that are just going to rile up their audiance and deserve their low score. Grow up.

Some flamebait of my own: I will try to not look down my nose at you for being a VB "programmer."


Anonymous Coward | more than 10 years ago | (#9033648)


Relative debugger checks user-supplied assertions (0)

Anonymous Coward | more than 10 years ago | (#9033572)

This sounds like a combination of debugging and test plans. More of a evolution and not much of that.

Revolutionary way of debugging what? (4, Interesting)

Rosco P. Coltrane (209368) | more than 10 years ago | (#9033575)

do you know any new debugger that has a revolutionary way to help us inspect the data?

I'm noy sure what the question is here. Any debugger will allow you to watch data. If your program is special enough that you can't use a standard debugger, you probably need to write a test suite to go with it (and well, for any reasonably sized project, you should anyway).

That's to help you find "surface" bug, i.e. to catch things like misaligned words, wrong data types, buffer overflows ..etc...

For deep structural problems, like when you try to code something and you have no clue how to go about it, and the end result is just not good and never going to be, the cure is usually a total rewrite, so debuggers won't help you there. That's a problem due to bad architecture of the code.

So, I'm not sure anything else is required. FYI, when I code, I believe I have enough experience to architecture and code something relatively clean the first time, then because I've done it for many years, I sort of "instinctively" expect to find a certain amount of this or that types bugs. And usually, I can fix them without debugging because they jump at me. When they dont (and I can do it), I pull out the old "print to stdout" debugging (or LED wiggling, sound generating ... on headless embedded boards), and that's usually enough to catch a 99% of whatever bugs remained. Normal debugging techniques using debuggers, or the test suite I made for that particular piece of code, takes care of the rest. My guess is, if you need anymore than that, it's probably that you lack experience.

new and revolutionary technique for deamonnews (-1, Troll)

Anonymous Coward | more than 10 years ago | (#9033586)

put out a fuckin' newsletter more than once a year, you fuck-tards!

old technique... (3, Insightful)

hak1du (761835) | more than 10 years ago | (#9033589)

Comparing the "state" of multiple implementations or versions of code is an old technique. You don't need a special debugger for it--you can use a regular debugger and a tiny bit of glue code. Alternatively, you can insert the debugging code using aspects (

However, like many programming techniques, most real world programmers won't know about them unless they can shell out $1000 for a tool; reading a paper or book just would be too much intellectual challenge, right?

This news item seems to be a thinly veiled attempt to drum up business for that company.

Visual software testing (4, Informative)

Novus (182265) | more than 10 years ago | (#9033596)

On the subject of software debugging techniques, I'd like to point out visual testing [] , which (basically) allows you to try out method calls and fiddle with variables and examine the results (including execution history) graphically. MVT [] is a prototype visual testing tool for Java.

Does anyone know of a good debugger debugger… (0)

Anonymous Coward | more than 10 years ago | (#9033598) debug the user-defined assertions that I have to feed into the relative debugger.

hee... (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#9033599)

what dilbert thinks about this?

nothing new (4, Informative)

hak1du (761835) | more than 10 years ago | (#9033603)

There has been almost nothing new in programming environments or debuggers over the last 10-20 years.

Almost those features you see in Visual C++, Visual Studio.NET, Eclipse, NetBeans, etc. have been around in IDEs since the 1980's. Debuggers have allowed you to step forwards and backwards, see the source code, examine data structures graphically, and modify the running source code for about as long.

If anything, current commercial IDEs and debuggers still haven't caught up to the state of the art.

Re:nothing new (1)

brondsem (553348) | more than 10 years ago | (#9033688)

If anything, current commercial IDEs and debuggers still haven't caught up to the state of the art.
Then where is the state of the art, if not in commercial apps (or commercially-backed ones like Eclipse)?

Polyheaded Debugger (4, Funny)

N8F8 (4562) | more than 10 years ago | (#9033626)

The technique I've found most effective is to run many simultaneous debugging sessions in parallel. My debugger of preference is a semi-autonomous intelligent agent that seeks out defects in a random fashion. I call this type of agent a "user".

Less Debugging Technique, More QA Tool (1)

yebb (142883) | more than 10 years ago | (#9033630)

It sounds like this could be used rather effectively as a QA tool. Machine 1 running version 1.23 of the software, Machine 2 running 1.24 running on the same data and should produce the same results.

Automated regression testing etc.

Blinking Lights (1)

Detritus (11846) | more than 10 years ago | (#9033631)

For systems that don't have a console, and even for those that do, a parallel port connected to a set of LEDs can be very useful. you can run the system at full speed and monitor important events on the LEDs.

Hummm yeah (0)

Anonymous Coward | more than 10 years ago | (#9033632)

The problem with relative debugging is that it assumes that you have a "reference" implementation. What if you're making the reference implementation?

I think that the people making the tool have missed the point.

A better solution (2, Informative)

Morgahastu (522162) | more than 10 years ago | (#9033635)

A better solution is to make your program generate a log of everything that happens, when an object is created, when an database connection is made etc.

And when you launch the program in debug mode everything is printed to a log file and when it crashes or a bug occurs you can just halt everything (if it hasn't crashed) and look at the log to see what it was doing.

Different levels of logging could be used. Say level 1 with the most basic logging (database connections, disk access, network access, etc), level 2 includes all level 1 plus network traffic, level 3 has all object creations, etc.

ex: logEvent(3,"DBO_Connection create");

Some ideas (5, Informative)

AeiwiMaster (20560) | more than 10 years ago | (#9033647)

They might not be revolutionary, but the is a few ideas
which can be just to reduce the number of bugs in a program.

1) 100% unit test coverage of your programs. []
2) Statistical Debugging []

3) Valgrind []

4) The D programing Language []
with build in support for unit testing, contracts and class Invariants.

Just another tool (1)

kabdib (81955) | more than 10 years ago | (#9033649)

Things I have used in debugging: A debugger, when available. No debugger, when the available debuggers have been worse than the disease (MPW, augh). The venerable printf, or its equivalent. Logs of all kinds. Whole machine state that you get from a machine through a serial port (tap foot for several hours). Nano logs written to memory (to catch race conditions). Flashing LEDs. Speaker beeps. Floppy disk track seeks. An AM radio held next to the machine. A photocopy machine (to get a permanent record of a register dump from the face of a hand-held machine). Cans of coolant spray. Heat guns. Logic analyzers (yay!).

This is just another tool, and it looks like it doesn't even work that well on the really hard problems, or even moderately complex multithreaded apps. It's more like an assert tool. Reminds me a lot of the stuff that Tandem was doing to scale availability (read Gray's Transaction Processing for a good description).

Data logging (3, Informative)

mrm677 (456727) | more than 10 years ago | (#9033654)

Don't trivialize the data logging approach to debugging.

In complex, multi-threaded systems where you are debugging timing events more often than programmer logic, data logging (aka print statements) is probably the only technique that works.

In fact, one of the first things we implement in embedded systems is a data logger that can spit out your print statements over RS232. Yes, we can single-step through code using in-circuit emulators and JTAG interfaces, however I found this rarely useful.

Re:Data logging (4, Insightful)

Tim Browse (9263) | more than 10 years ago | (#9033752)

Of course, as many people who debug multi-threaded programs have found, using print routines to output logs can make the bug 'go away', because quite often CRT functions like printf() etc are mutex'd, which serialises code execution, and thus alters the timing, and voila, race condition begone!

I know it's happened to me :-S

Debugging is much, much nicer... (4, Informative)

Anonymovs Coward (724746) | more than 10 years ago | (#9033660)

in a lot of higher-level languages, eg functional languages like lisp, haskell and ocaml. But not only debugging: in these languages you tend to write code that doesn't have bugs in the first place. No need for mallocs, no buffer overflows, no memory leaks. And if you're careful to write in a functional style, no "side-effect" bugs (variables that change value when you weren't expecting them to). For a language that started out in the 1950s, it's amazing how far ahead it was and still is as a development environment. This paper [] is a fascinating read, especially the section on Worse is better [] that describes why Unix/C won. And there are other languages like the ML family and Haskell. OCaml [] (Objective Caml, a descendant of ML) is as concise and elegant as python, but produces native-code binaries quite competitive in speed with C, and occasionally faster [] . I'm wondering why anyone uses C-like languages anymore.

Re:Debugging is much, much nicer... (1, Insightful)

Anonymous Coward | more than 10 years ago | (#9033760)

I'm guessing it's because writing a device driver in LISP is not anybody's idea of a good time?

Seriously though, not all bugs in a program have to do with allocation or buffer overflows. Besides, there are tools to help people with these problems. Most interesting bugs are beyond these types of distractions and can happen regardless of the language, or are you asserting that functional language programs always work perfectly the first time you run them?

Re:Debugging is much, much nicer... (1)

mattgreen (701203) | more than 10 years ago | (#9033775)

There goes your karma forever for implying that C is unnecessarily low-level. That is, saying nothing of implying that Unix isn't a perfect OS.

RetroVue (3, Interesting)

Stu Charlton (1311) | more than 10 years ago | (#9033664)

This is going to sound like a plug, but I have nothing to do with this company or product - I just thought it was really cool.

When I was wandering through JavaOne last year, I ran across this booth by VisiComp, Inc. who sells this debugger called RetroVue [] . I think it's an interesting attempt at bridging the gap between live-breakpoint debugging and logging.

The main issue with debugging vs. logging is that logging provides you with a history of operations that allows you to determine the execution order and state of variables at various times of the execution, something that debuggers don't actually help you with.

RetroVue seems to instrument your Java bytecode to generate a journal file. This journal file is quite similar to a core file extended over time, by recording all operations that occurred in the program over time: every method call, every variable assignment, exception thrown, and context switch. RetroVue then allows you to play back the execution of the application.

It includes a timeline view to jump around the various execution points of the program, as well as an ongoing call-list to show the call sequence that has occurred. It also notes every context switch that the VM makes, and detects deadlocks, thus making it a great tool for multi-threaded application debugging. You can adjust the speed of the playback if you would like to watch things unfold in front of you, or you can pause it at any time and step through the various operations. Want to find out when that variable was last assigned to? Just click a button. Want to find out when that method is called? Same.

It's not free/cheap, but it seems quite useful.

Unit testing (2, Insightful)

Tomah4wk (553503) | more than 10 years ago | (#9033690)

It seems to me that a lot more effort is being put into creating good unit tests to identify and prevent bugs, rather than debugging running applications. With an automated testing framework you can seriously reduce the amount of time spent on manual debugging and fixing as the bugs get identified as early as compile time, rather than run time.

Print statements good, debuggers good (3, Interesting)

crmartin (98227) | more than 10 years ago | (#9033697)

thinking is better.

debugging what? (1) (745183) | more than 10 years ago | (#9033706)

...variables are compared...with variables in another reference program that is known to be correct.

So, this isn't for developing or implementing a new algorithm.

However, it might be a step closer to fully automating the re-implementation of existing ones ...which is inherently a rote task to begin with.

The best debugging (2, Informative)

Decaff (42676) | more than 10 years ago | (#9033707)

The best debugging system I have ever used is in Smalltalk. Its possible to stop code at any time, and then data can be inspected and altered, new classes coded and methods re-compiled without interrupting execution. When changes have been made code can be re-started or resumed.

Features like exception handling with full stack trace in Java are great, but nothing beats the Smalltalk system of suspending execution and keeping the application 'alive', so it can be modified, inspected and resumed, when an error occurs.

Re:The best debugging (1)

noda132 (531521) | more than 10 years ago | (#9033758)

Features like exception handling with full stack trace in Java are great, but nothing beats the Smalltalk system of suspending execution and keeping the application 'alive', so it can be modified, inspected and resumed, when an error occurs.

GDB does this. gdb --pid=[running process].

Re:The best debugging (1)

koali (175176) | more than 10 years ago | (#9033773)

Eclipse (and I guess other IDEs do as well) supports hot-code swap with JDK1.4. Never used it much myself, though...

Valgrind, the ultimate debugging tool (2, Informative)

bluefoxlucid (723572) | more than 10 years ago | (#9033718)

Memory leaks and such are easily tracked with valgrind, although for basic logic errors you want to use the printf() and gdb methods.

Valgrind is and requires that you turn off all pax protections for the binary you wish to debug.

How about single step *backwards* (1)

Beatlebum (213957) | more than 10 years ago | (#9033751)

This would be pretty difficult to implement efficiently since a single instruction has the potential to make massive state changes, however, even a limited implementation would be extremely useful and would provide an alternative to restarting the application.

Rewind (3, Interesting)

jarran (91204) | more than 10 years ago | (#9033756)

O'Caml [] has a replay debugger. You can run your program in the debugger until it crashes, then step backwards through the code to see what was happening before it crashed.

Very handy, IMHO, although the O'Caml debugger sucks in other ways. (E.g. no watch conditions.)

Inspector and Valgrind (1)

Bluelive (608914) | more than 10 years ago | (#9033771)

I wrote a little jar that spings up an awt window filled with all the information about fileds and values about an java object, allows to browse to the fields and such, really handy when you need to debug something related to a datastructure. That combined with exceptions and println, i never use a debugger in java. For C, valgrind has revolutionied debugging.

I'm surprised. (1)

/dev/trash (182850) | more than 10 years ago | (#9033799)

21 comments, and no one has mentioned that using eXtreme Programming, there would be no need for a debugger.

*Bzzzt* (3, Insightful)

bmac (51623) | more than 10 years ago | (#9033813)

Nope, looks like marketroid hype to me. Answer me this: what is the point of comparing two separate identical runs of a computer, except in the case of testing platform equivalence, in which case the output of a test set can simply be diff'd.

The key to their idea is that The user first formulates a set of assertions about key data structures, which equals traditional techniques. The reason such traditional techniques have failed and continue to fail is that those assertions are always an order of magnitude simpler than the code itself. These people forget that a program *is* a set of assumptions. Dumbing it down to "x must be > y" doesn't help with the complex flow of information.

Peace & Blessings,
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?