Slashdot Mirror
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."
...these guys allow me to upload any linux executable, which they will then execute in a gdb context?
Alfred, prepare the rootkit!
All's true that is mistrusted
Now we've got it debugging the code, we only need to get it started writing the code, and we're sorted :-)
Simon
Physicists get Hadrons!
Why ask Igor when you can ask slashdot? :-)
...When I was trying to figure out what the hell was making my program crash! I figured it out, and got it fixed, but it took me 6 hours to pin point it! Something like this can (hopefully) be very useful next time I have a program that unexpectedly seg faults! =)
This space for rent, inquire within.
I site's admin configured the site to forward visitors to the google cache of the site, but if you actually try to debug something, you get back to the real site, poor admin, he thought he could get away from /.ing!
The IT section color scheme sucks.
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.
No problem. Igor runs your program in a sandbox whose contents get restored with each new submission.
www.askigor.org - automated debugging service
FYI, your problem is the extra "a" in "baar".
Find out what's wrong with that crap.
Life in Orange County
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.
Please read the article.
The tool executes your program multiple times, and examines the internal state of the program (variable values and memory contents) at various stages in the execution.
It then automatically isolates the root cause of the failure. This is pretty cool stuff, and ought to save a lot of time tracking down complex bugs.
-Mark
Smart kids. Redirecting to their google cache.
I wonder what happens on google's next cache update, if you're doing something like that. Do you get a google cache within a google cache? Or does google just forget about you?
There are no trails. There are no trees out here.
We're redirecting only if you come from /.
That's very clever! Smart cookies.
It certainly mitigates the awesome server-melting power of the slashdot effect
While not applying AskIgor (being a huge mix of Python, PHP, and SQL) on itself, we have applied delta debugging on various parts of AskIgor to detect failure-inducing code changes, and especially failure-inducing GDB commands.
We're currently working on Eclipse plugins written in Java, and working on Java - and these will work 100% on themselves.
www.askigor.org - automated debugging service
I notice that Fedora Linux is full of bugs, however this site won't let me upload the entire first cd.
This fields has decades of history. A good starting point, should you like to explore it, is here.
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 :-)
www.askigor.org - automated debugging service
Nice google-like interface...
What, you mean like a textbox?
-3Suns
~~~~
The Revolution will be Slashdotted
I remember reading a rant about a year ago. Someone wrote a replay tool for program executions for under linux, I think 2.0 or 2.2. They dropped it because nobody cared about it (probably because nobody knew about it), and they got sick of updating it constantly for new IOCTL's as the kernel constantly changed.
I think it was Carmack lamenting its loss.