Webservice Debugs Linux Binaries While-U-Wait

null-und-eins writes "A new webservice offers automatic debugging of Linux binaries. It takes a (with "-g" compiled) binary and two invocations where one fails and the other doesn't. The service repeatedly runs the two programs and tries to find the smallest difference between the two that causes the failure. Nice google-like interface with statistics about its own performance."

Comments

Re:Let me get this straight...

[Hentai]

Let no good deed go unpunished.

Hopefully they've thought of this and won't let it screw them up too badly. A shame that human nature is such that the first thing people think about when they see a nifty new service is how to shit in it and ruin it for everyone else. (witness /.)

This is cool but

[Safiire Arrowny]

I think this is a neat idea, but I wonder why it isn't a standalone program you can run yourself as well as/instead of a web interface.

This is because I wonder why he wants to run the risk of running foreign binaries (sandbox or not) when he could have just not done that. There doesn't seem to be any advertising on the page, so that isn't it.

Oh well, maybe he just thinks it's cooler this way, actually it kinda is, so long as it's safe for him I guess.

Open-Source Community: Beta=Flaky, Mature=Stable

[phorm]

You must be joking. While some of the more "mature" projects are definately solidly coded, some of the others are nightmares. Try mixing several different coding styles, nights coding on only caffeine, starting, stopping, and losing your place...leaving debug to-fix-later code in by accident...

Open source suffers the same problems as closed. In some projects moreso, as the variance of different coding styles/standards-adherance can lead to very interesting things happening. Even some mature projects have this problem, I've heard of some common ones where a rewrite was considered, because as the code evolved and was added to, the author(s) learned much better coding as it progressed but left the core a bit flaky.

Re:Doesn't seem that useful.

[Andreas Zeller]

We're talking about two different issues here - reproducing the bug and actually understanding how it came to be. Most bugs are easy to reproduce and easy to understand, just by re-invoking them and looking at the stack trace.

Some bugs, though, are hard to reproduce, which means that you should set up appropriate isolation and monitoring layers in your program. The recent issue of Communications of the ACM, for instance, has a nice article on record/replay of program executions, which solves all problems of reproducing runs - in principle, that is, because such tools are not readily available yet.

Now there's some bugs that are hard to understand, especially those where there's a long delay between the defect being executed and the experienced failure. Think about a compiler that generates bad code. This is not an issue of reproduction; nor can the problem be solved by examining the stack trace. You have to work your way backwards all through the execution to understand the cause-effect chain. This is where AskIgor can really help you.

And, yeah, I got 12 years of C/C++ programming and debugging experience, too :-)