Slashdot Mirror
Debugging in Plain English?
sameerdesai writes "CNN is carrying a story about Researchers from Carnegie Melon: Myers and a graduate student, Andrew Ko, have developed a debugging program that lets users ask questions about computer errors in plain English: Why didn't a program behave as expected? I guess with recent exploits and bugs that were found this will soon be a hot research topic or tool in the market." We recently did a story about revolutionary debugging techniques; the researchers' website has some papers and other information.
"Because you can't code worth a damn."
Mr. Debugger, I'm running a multithreaded perl app using perl 5.8.3's ithreads. I am using DBD::mysql to talk to a local mysql database. At the program start I spawn a child thread that waits for a thread::queue to be filled with data. Once the child thread receives data it spawns several children of its own to process the data. Each grandchild forms its own dbd connection and successfully processes the data, then gracefully closes the connection and waits to be joined.
The problem arises when the controlling child thread begins to join the grandchildren. Despite the mention of global destruction, the entire program is not exiting - just the grandchildren are being joined. When the grandchildren join, perl dies with the following error:
Attempt to dereference null pointer during global destruction.
When performing the same style operation without using DBD (and thus not actually doing anything useful) the error does not occur. Initially, this appears to be a thread-safety issue with DBD however when isolating the child and grandchildren in their own test program (so the controlling child is the main program and the grandchildren are spawned worker children) the error does not appear.
Help me O great plain English debugger. You are my only hope!
Karma: SELECT `karma` FROM `users` WHERE `userid`=138474;
printf, System.out.println, warn, print, etc.
Oh ... this will be wonderful for security the world over. If it works ...
Microsoft Programmer: "Why does our software suck?"
*computer hangs, then bursts into flames from the load*
In soviet russia, You ask not what country do for you, but what you do for country!
Oh wait...
Because I debug in plain english anyway, I'm always saying "Why the hell won't you work you piece of shit?!" and "Listen here you piece of shit if you insist on seg faulting again then I'll show you where you can put those damn indices!"...
So... now the computer can actually respond to my threats and questions. Excellent!
Mike.
(Yes, I did RTFA.)
Mmmm......sacrelicious.
Untill I can have a full conversation with a computer (a la the Turing effect, not the limited versions that Alice et. al. can accomplish) I'll be happy with source code, thank you very much. It's just another layer blocking me from the code anyway (read In the Beginning... lately?).
[...] "Forty-two," said Deep Thought, with infinite majesty and calm.
It was a long time before anyone spoke. Out of the corner of his eye Phouchg could see the sea of tense expectant faces down in the square outside.
"We're going to get lynched aren't we?" he whispered.
"It was a tough assignment," said Deep Thought mildly.
"Forty-two!" yelled Loonquawl. "Is that all you've got to show for seven and a half million years' work?"
"I checked it very thoroughly," said the computer [...]
www.kitchengeek.com -- Nosh for
WHERE THE FUCK DID MY THESIS GO??? ...if it can bring calm to these situations, we may have a contender for the Nobel Peace Prize.
Know what I like about atheists? I've yet to meet one that believes God is on their side.
"Whyline, has been used only to debug programs in Alice, an academic programming language with a limited vocabulary of commands to make interactive 3-D worlds, like video games."
"Adding Whyline to a different language, like Java, which is 10 times as complex, could limit how much Whyline can help. So Whyline is a very long way from getting incorporated into the world's most widespread software, Microsoft Corp.'s Windows operating system. (When asked about its own debugging efforts, Microsoft didn't comment.)"
Which means at the moment its all speculation, and only works for very simple (hello world) applications. By the time this program is useful, we'll have robots (like Millenium man), who will do all the debugging...
All these talks of "revolutionary" debugging techniques bother me a little. There's only one debugging technique, and that's the debugger's skill and experience. Debuggers, traces, logs and other printf()s and LEDs flashing are just tools.
Andrew Ko's invention is just another tool. It won't do the debugging for you. Just like modern cars have diagnostic computers, but somehow it appears you still have to fork off $30/hr for the workmanship to get it fixed...
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Article says adding Whyline to java makes it 10x more complex. Seems to me like just another example of Computer Science grad students trying to justify their existence.
Plain english or not, make it easy for someone to debug and I'll be out of a job. I like finding other people's mistakes and being the one to say "Uh, dude, this is where you screwed up, but I fixed it for you".
Where's the fun if I can't point out someone's shortcomings?
So when is the Hawkeye movie coming out?
Why didn't a program behave as expected?
Is it because didn't a program behave as expected that you came to me?
Hello SeanTobin(138474)!
I am Surest K. Padebugtel of Mrdebugger.com
I understand that you are having a problem with I'm running a multithreaded perl app using perl 5.8.3's ithreads. I am using DBD::mysql to talk to a local mysql database. At the program start I spawn a child thread that waits for a thread::queue to be filled with data. Once the child thread receives data it spawns several children of its own to process the data. Each grandchild forms its own dbd connection and successfully processes the data, then gracefully closes the connection and waits to be joined.
Please to reboot your system.
Has this helped your problem? (Click "Reply" to this trouble ticket if you feel you need further assistance with I'm running a multithreaded perl app using perl 5.8.3's ithreads. I am using DBD::mysql to talk to a local mysql database. At the program start I spawn a child thread that waits for a thread::queue to be filled with data. Once the child thread receives data it spawns several children of its own to process the data. Each grandchild forms its own dbd connection and successfully processes the data, then gracefully closes the connection and waits to be joined.)
Thank you for your interest in Mrdebugger.com!
Sincerely,
Suresh K. Padebugtel
Hey moderators, this is NOT FUNNY! I've been wresteling with this problem off and on for nearly 3 months now. (I've come up with several varried solutions, but none of them are the way I want it to be done)
Karma: SELECT `karma` FROM `users` WHERE `userid`=138474;
From the pdf on whyline, it seems to work with the Alice language. Alice seems to be very rigid in its design, allowing English lookups (rather like naming variable in English-word format like 'pac_resize').
This is a more user-friendly version of tools like grep and awk.
This type of debugger would seem difficult to make in the lower-level program tools without rigid naming conventions. Or else the searching would be on high-level concepts like graphic resizing that would be searched on the language functions that perform the resizing (regardless of data-var name).
I do have to disagree with their definition of a programmer: "If you've created a spreadsheet, made macros in Excel or Word or used a Web application to fetch news about your hobby or favorite celebrity, you've programmed". Although technically usable in definition, a Word/Excel macroist does not a programmer make.
When I think about some of the bugs I have found (and coded), the Whyline approach seems very far-fetched. The degree of self-awareness (introspection) required by something like this makes it seem like the program would be able to avoid the trap in the first place. It would require the "analyst" or "observer" module to observe not only a stack trace and PC trail, but also would require the module to understand what is supposed to occur.
I don't expect this early research tool to catch all of these, but I'd like to hear the researchers' response on how their system might (after years of development) answer questions about some of these bugs:
- Why did the Mars Pathfinder software deadlock (priority inversion)
- Why did the Mars Polar Lander crash (improper state management)
- Why did the Ariane 5 blow up (arithmetic overflow in a register)
- Why did the Patriot missiles miss in the 1991 Gulf War (accumulated time error)
- Why did a radiation therapy machine zap patients with the wrong doses (inconsistent state between GUI display and internal software state)
I'm sure there are some others on comp.risks and elsewhere.
Another point: this approach is still "just" a testing tool. In other words, it can only find errors on paths that have actually been taken in tests, which means the testing program must cover enough cases to generate the runtime errors in the first place. In all of the above cases, it was the testing program that permitted the bugs to be fielded.
I'm not a fan of controlled English systems, because they're misleading. They are computer languages, not natural languages, and people often misunderstand the semantics. They are as exacting to write as code, but more verbose. If the controlled English isn't quite working, it can be intensely difficult to debug.
:- parent(X,Z), parent(Z,Y).
I've seen efforts where knowledge representation languages (CycL and Prolog come to mind) are translated into English for validation. That's not a perfect tool, but it's actually not dissimilar from what I do in my mind when I read these languages: translate
grandparent(X, Y)
into
X is the grandparentof Y if X is the parent of Z and Z is the parent of Y.
or even:
Y is X's grandparent if X is Z's parent and Z is Y's parent.
So you write code, concisely and precisely, and translate it into easier-to-read but less precise English. I'm not sure if this technique has been adapted to "business rule" systems like iLog, but it might work well there.
This reminds me of back in approx 1985 or so, someone "invented" a human language programming environment called "The Last One" or something like that. This would supposedly make it simple to write programs without having to learn C etc. Some programmers quaked in their boots. However the real issue with programming is learning the contructs, not the language (ie. if you understand what a linked list is, then writing one in C vs Pascal is pretty simple). Anyone that thinks that programming in English is easier is seriously misunderstanding programming. The ultimate test is to look at the languages that have survived: The more "human readable" languages like COBOL have not survived, but the more cryptic ones like C have. The big "killer app" for making programming simple for the non-programmer was the spreadsheet and that's hardly a natural language.
Now debugging is pretty much the same deal. Verbose English debugging interfaces might make it simple to learn to do very basic debugging, but once you get into things a bit deeper (and get more experienced), English becomes a huge liability and you'll be wishing for more concise and expressive languages.
Engineering is the art of compromise.
> My program crashed.
What does that suggest to you?
> There is a bug somewhere.
Does it make you happy to know there is a bug somewhere?
> No.
Why are you so negative?
> Are you going to help me fix this bug?
We were discussing you, not me.
He also said that there were no silver bullets, and he said so over twenty years ago. It seems that every few years a generation arises who haven't read him. Put natural language debugging on the pile with case and all the others.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
In the products I'm involved with I often get stupid reports from the field of the form "framing error causes unit to reset". When I get one of these, first thing I do is get back to the user and figure out exactly what they saw and what heppened withouth them trying to figure out the symptoms. In the "framing error" problem, what was really happening was that a power glitch was being caused when the RS232 cable was attched (because of bad grounding). This caused a reset. However, the user was a "super user" who knew bad things happen to serial data when you plug/unplug cables. One of the buzzwords he knew about was a framing error. So he "half solved" the problem by saying that a framing error caused the problem.
There is a big difference between observing and fixing problems. QA is about observing, not fixing, problems. It is better to provide a good way for users to make accurate error reports (eg. backtrace/log/whatever) than try have them try explain what went wrong.
Engineering is the art of compromise.