h a l f b a k e r y"Put it on a plate, son. You'll enjoy it more."
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
[Edited (see below)]
When debugging, once you reached the problem, its too late. Wouldn't it be great if you had the whole app's condition saved so you can press BACK, (sort of "UNDO") while debugging?
Since its not practical to save the whole PCs memory, at least you can save the process' memory,
one visible (to debugger) step at a time. So it wont work for multi-process or cross process programs, but will work great for self contained programs, and - hey - that's what you'll be fixing: the code that YOU have available to you. If its outside your scope, you can only change YOUR code anyways.
So you press RECORD, and the PC stores an image of the process' memory for each step, or perhaps all the local and public fields available to the program, and pressing STEP BACK, brings back the condition you were in.
[[added later]]
I suppose if the Eclipse or MSVC people get working on that kind of a feature, it would NOT take giant amounts of memory. Rather they would think of ways (this is HALFbakery) to dynamically reconstruct the stack, and only change the current available parameter VALUES that were originally different. So you only store a series of values.
Then if you save incremental changes only, each step will have a small footprint.
Perhaps an incrimental debugging state could be stored, that way it would use less time and space when you progress in the debug program.
Omniscient debugging
http://www.lambdacs...ugger/debugger.html
Sounds like a superset of this functionality [Srimech, Jan 16 2008]
WinHex
http://www.winhex.com/winhex/index-m.html
Lets you see exactly what's going on - providing you know where to look. [zen_tom, Jan 17 2008]
Time-traveling virtual machines (PDF)
http://www.usenix.o...neral/king/king.pdf
Samuel T King, George W. Dunlop, and Peter M. Chen; U Michigan; Debugging operating systems with time-travelling virtual machines, USENIX '05. [jutta, May 30 2008]
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Annotation:
|
| |
I baked something similar to this for a client a few years ago. We basically identified every single place where the program interfaced with the "outside world" and wrote enough information to a disc file that the whole execution run could be replayed just by reading info from the file instead of from the OS. Once you've captured an intermittent bug once, you can reproduce it at will, every single time. |
|
| |
The files get _huge_. 50Gb trace files weren't all that uncommon. |
|
| |
We didn't have a "STEP BACK" button. That would have made it vastly more complicated as any time the compiled program writes a value to a memory location you need to save the old value somewhere ... it wouldn't have been practical at all. However you could set a breakpoint on the "current event counter" and stop the program when it got to just before the crash, which was just as useful in practice. |
|
| |
It was only possible because the program in question was written to be highly portable and contained all its own abstraction layers for interfacing to the screen, keyboard, network, etc. If it had made any use of multiple threads, or of bits of the OS which were outside our direct control, it wouldn't have been at all practical to make it work. |
|
| |
I had the great pleasure of being told "That's impossible" to my face, by their head techie, in front of half of the company, and then going on to demonstrate it working right in front of him. They're still using that bit of code but I suspect the aforementioned head techie is long gone! |
|
| |
I suppose if the Eclipse or MSVC people get working on that kind of a feature, it would NOT take giant amounts of memory. Rather they would think of ways (this is HALFbakery) to dynamically reconstruct the stack, and only change the current available parameter VALUES that were originally different.
So you only store a series of values. |
|
| |
Then if you save incremental changes only, each step will have a small footprint. |
|
| |
Isn't this what breakpoints are for? |
|
| |
Write a dump routine that will report all of the things that you are interested in, and have it splurge at just the point in the code where you think the issue is. |
|
| |
If you're really clever, you'll allow yourself the luxury of editing various values in this state dump, before allowing the system to continue (as if nothing has happened) |
|
| |
In other words, there's nothing stopping you from coding your own debugging routines. |
|
| |
This sounds like omniscient debugging (see link). The difference here is that you're choosing places to record state, rather than recording all of them. |
|
| |
Thanks [srim]. I edited the entry, and added my anno to the main idea. I think it answers your question.
Hi [zen], no breakpoints help you stop somewhere, and carefully continue. But it always happens that you miss the exact point of failure and then have to run the whole thing again, because the data is ruined. Sometimes the date was recieved after a long wait (reason for this thread of thought) and sometimes you won't be able to reconstruct the conditions that you reached just now during debugging. |
|
| |
With this idea, you can jump back (maybe even several steps) to an immediate state, without running the whole program again. |
|
| |
Example: After 20 minutes of slowly progressing thru your program carefully skipping this and that, so that you reach the problem point, you are advancing towards a dangerous point and then BANG - your in the catch in the calling class. Just setting back wont do the job, because you lost all your data accumulated till the crash. Clearer? |
|
| |
whats VM ehrleMann (Virtual Machine? and if so how does that help?) |
|
| |
I've thought such a thing would be quite useful, and practical, in an Atari 2600 emulator since the amount of state information is fairly small. Rather difficult to scale up to a PC-sized application, though. |
|
| |
[supercat] machine-code monitors have long been available that do exactly this. You have to know what it is you're looking for, but breaking out of a program and into a monitor used to be the standard method of debugging code. |
|
| |
These tools still exist today, I'll post a link to a PC thing that lets you look directly at what's in RAM, or on disk - and if you are brave enough, allows you to edit it directly. |
|
| |
//[supercat] machine-code monitors have long been available that do exactly this. You have to know what it is you're looking for, but breaking out of a program and into a monitor used to be the standard method of debugging code.// |
|
| |
Certainly tools exist to look at the current state of a system, and tools also exist to log everything. What would be helpful would be something that could sample all I/O to a system, and capture/log the state of the system at e.g. 60Hz, so that whenever anomalous behavior was observed one could backtrack to see what caused it. |
|
| |
My present debugging approach for the 2600 is to use massive log files. These work if I can predict in advance when to start and stop capture. On the other hand, with my present tools, one second worth of program execution yields about 50-100 megs worth of log data. |
|
| |
Since the Atari 2600 only has 128 bytes of RAM, and probably less than 128 bytes of other system state, capturing the full system state 60 times a second would only require about 8k/second. That's a pretty huge improvement over 50-100 megs/second. |
|
| |
Wait! You all agree that this would be great. Your just saying its not practical, because of the volume of info. But this debugger doesn't need to check at any Hz frequency. Its not realtime. Each step you make in the debugger it looks at the CHANGES to the VM (all variables) |
|
| |
Something pretty close to this is an existing topic of research and won "best paper" at USENIX'05. They actually did a demo. You run the thing you want to debug in a big virtual machine - in the paper's case, a kernel - and record just enough information to be able to reconstruct the previous state each time the state changes. That's far from everything. Then you step through it with an instrumented debugger and can jump back and forward to your heart's content. |
|
| |
//won "best paper" at USENIX'05//
...wonder why I didn't weigh in on this earlier: they're giving out awards for fixing mistakes ?
"we just got an award for moving the spark plug out of the gas tank, yaaaaay teeeeeeam" |
|
| |
// ...wonder why I didn't weigh in on this earlier
In order to "weigh in", you'd have to have something of substance to say. |
|
| |
//you'd have to have something of substance to say//
Like a rant against the celebration of mediocrity in so-called "professional" programming circles ?
Or a more specific rant against "organic" programming (lack-of-)methodologies for fixed-spec systems ? |
|
| |
Or putting it another way [jutta] when you peruse the log, how happy are you to see my 1 anno that has been edited 9-10 times 'cuz I'm too lazy to use Notepad ? Bit of a waste of time for all concerned, no ? :) (heheh, sry btw) |
|
| |
50 GB trace files? The thing is, you frequently only want to reverse a few dozen steps. |
|
| |
It would be impossible to store the information to reverse every single step since the start of execution, unless execution time is very short. But it is possible to store the information required to reverse say the last million lines of code. |
|
| |
It seems to me that this is not particularly difficult to do and should have been in every commercial debugger since the early 90's |
|
| |