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."
...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.
They actually might be ready - somewhere on the site it says that they'll release a standalone version (for local runs) once Igor debugs 1000 programs. This way the get a decent-sized test so they can squish more bugs. And yes, they use Igor to delta debug itself :)
I presume igor had some bugs when you were writing it. Was it able to find it's own problems? :)
Well that fine for the file system, but does it have protected memory space for each session? If so, wouldn't that get kind of demanding on the system? If not, how do you stop people from messing with the core OS?
-R
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
This fields has decades of history. A good starting point, should you like to explore it, is here.
I don't recall ever getting to the point where I could crash a program at will, with some given input, and yet the bug wasn't fairly obvious and easy to find just from a stack trace and maybe 2-3 minutes of line by line stepping.
Neat technology, very little real world use. IMO.
I mean, honestly -- have YOU ever seen a function or class or subroutine in Linux that WASN'T damn near perfectly coded?
Yes, most of it. The majority of recent open-source software is badly-written, non-portable dreck that'll build, sometimes, on a short list of Linux platforms.
All the worlds a RedHat box is as bad an assumption as all the world's a Sun or all the world's a VAX.
The redeeming factor is that a major reason for this is that there's so much open source code. So while the fraction that is well written, stable and portable isn't that high the absolute amount is pretty large and climbing.
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.
multithreaded programs? Does it catch race conditions and such?
This program (which needs updating to more recent kernels) allows one to replay a binary execution.
http://old.lwn.net/1999/0121/kernel.php3
http://lwn.net/1999/0121/a/mec.html
Apparently its been out for *8* years, and has had exactly 3 people download it. Horrible -- its a feature I'd kill to have, and a feature linux should have.
In January, Jamie Zawinski made a post about the possibility of running a debugger backwards...