Webservice Debugs Linux Binaries While-U-Wait 219
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."
Re:Let me get this straight... (Score:5, Insightful)
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... (Score:2, Insightful)
wellsir (Score:2, Insightful)
Hence this [askigor.org].
This is cool but (Score:5, Insightful)
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... (Score:3, Insightful)
Most web servers cant handle the http requests associated with the Slashdot effect, and these guys are accepting uploads and running executables .
Open-Source Community: Beta=Flaky, Mature=Stable (Score:5, Insightful)
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 (Score:1, Insightful)
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. (Score:2, Insightful)
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. (Score:3, Insightful)
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 (Score:3, Insightful)
"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.