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

So...

[Jooly Rodney]

If you have a working version, why do you need the debugger?

wellsir

[SweetAndSourJesus]

Your program may fail if invoked one way and work if you invoke it some other way.

Hence this.

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.

Re:Let me get this straight...

[TedCheshireAcad]

Oh man these guys are gonna get pummeled.

Most web servers cant handle the http requests associated with the Slashdot effect, and these guys are accepting uploads and running executables .

perl -e 'while(true){ fork; }'

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.

fork() is a big problem for gdb

[Anonymous Coward]

int main () {
int pid;

pid = fork();
if (pid == 0) { .. }
..
}

$ gcc -g -o my_prog my_prog.c
$ gdb my_prog
(gdb) b fork
(gdb) r
(gdb) n
HA HA HA HA, half for you and another half for me.

open4free

Doesn't seem that useful.

[MisterFancypants]

Honestly, not to belittle the effort here, but in my experience if you've gotten to the point where you absolutely know that some input to your program will cause a crash it is very easy to find the bug and fix it.

The REAL problem bugs are the ones where the same input on different machines will give different results, or the same input on the same machine will give different results during different runs.

Kinda cool technology, I guess, but speaking as someone who has programmed in C/C++ professionally for about 9 years now, I just don't see this as being useful in 99.99% of debugging cases, and the ones where it might be useful are pretty easy to solve just by tracing the stack once you know what the 'problem' input is.

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 :-)

Patents

[Quelain]

Igor FAQ:

"The Eclipse plug-ins are licensed under the GNU public license." ...

"The basic Delta Debugging technique (narrowing down relevant circumstances by experiments) is not covered by any patent (as far as we know); in fact, we have released Delta Debugging plug-ins for Eclipse under a GNU license.

However, Passau University has filed international patents for the automatic isolation of cause-effect chains from computer programs--that is, Delta Debugging applied to program states. This is the core technology of AskIgor. This means that if you want to make money out of AskIgor technologies, you'll have to license the patent. (That's how Passau University attempts to get some revenue from its research.) Patent licenses are handled by the Fraunhofer Society in the BayernPatent initiative. "

GPL:

"For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program."

WTF?

Maybe there is some difference between what the Eclipse plugins do and what AskIgor does, but it's not very clear from the FAQ if that is the case.