• Advertisement

Archived

This topic is now archived and is closed to further replies.

My genius debugging idea

This topic is 5096 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

You can even have it for free. Why not the debugger saves the last couple of states of the run time application. So you will be able to take a few steps backward in the debug mode.

Share this post


Link to post
Share on other sites
Advertisement
That would effectively require a breakpoint at every line in the program (so it can be stopped and it''s state saved). So your program would run really slowly, and why would you want to step back anyway?

Share this post


Link to post
Share on other sites
quote:
Original post by Monder
That would effectively require a breakpoint at every line in the program (so it can be stopped and it''s state saved). So your program would run really slowly, and why would you want to step back anyway?

To deal with run time errors, which you cannot predict when exactly they will happen.

Share this post


Link to post
Share on other sites
quote:
Original post by Monder
That would effectively require a breakpoint at every line in the program (so it can be stopped and it''s state saved). So your program would run really slowly, and why would you want to step back anyway?

To deal with run time errors, which you cannot predict when exactly they will happen.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Yawn, why not do what everyone else does, run it under a debugger until it crashes, then place a BP a few lines back to observe what happens...

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
Yawn, why not do what everyone else does, run it under a debugger until it crashes, then place a BP a few lines back to observe what happens...

Because you have a segment of code that runs fine a 1000 times and only at the 1001 time it crashes.
So placing a breakpoint in that segment will stop the debugger only at the first time you enter that segment.

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
Yawn, why not do what everyone else does, run it under a debugger until it crashes, then place a BP a few lines back to observe what happens...

Because you have a segment of code that runs fine a 1000 times and only at the 1001 time it crashes.
So placing a breakpoint in that segment will stop the debugger only at the first time you enter that segment.

Share this post


Link to post
Share on other sites
With Visual C++ .NET if you run an application which then generates a run-time error like a memory-access violation error it will give you the option to debug the program and will show you the exact line in the source which generated the error. If the program is not one of your own then this isn't particulary helpful but it is extremely useful when it's your own game/app.

EDIT: dam typos

[edited by - Spudder on March 7, 2004 11:58:28 AM]

Share this post


Link to post
Share on other sites
.net only does that when the the applicaiton is set in debug mode otherwise it just throws an error the application unravels until a memory or other voilation is displayed to the user.

Share this post


Link to post
Share on other sites
You can do this with continuations, but I''ve never seen it in C++, nor do I think we will ever. Several functional languages can do it.

Share this post


Link to post
Share on other sites
It is possible, but unlikely, since it''s easy to place a breakpoint. If it''s crashing after n calls, just add a counter, check its value after the crash, and conditional-break there after n-1 hits.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster

Because you have a segment of code that runs fine a 1000 times and only at the 1001 time it crashes.
So placing a breakpoint in that segment will stop the debugger only at the first time you enter that segment.




Most debuggers will let you set a ''pass count'' for the debugger (ie pass this breakpoint 1000 times before breaking).

Mat

Share this post


Link to post
Share on other sites
quote:
Original post by Jan Wassenberg
It is possible, but unlikely, since it''s easy to place a breakpoint. If it''s crashing after n calls, just add a counter, check its value after the crash, and conditional-break there after n-1 hits.

What if it happens only when you walk your charcter a few steps, and it doesnt happen after a certain amount of times but after some unknown time?

Share this post


Link to post
Share on other sites
Then, young one, you learn the preferred way of debugging: The method of printf()! Whack printf() or equivelent in every other line - it''s just like having a breakpoint there, but it doesn''t actually stop, and those function are pretty fast these days unless you put them in inner rasterizer loops. Works everywhere, and is just as effective (although more typing) as any debugging method I know. I sometimes use in preference to the MSVC++ debugger...

Plus, congrats for figuring out the ''did you double post?'' checkbox on your last post (or just not double-clicking ''post'')

Share this post


Link to post
Share on other sites
I don''t see how you can call it debugging if you have to recompile.

But all the GDB apologists claim it is so.

Share this post


Link to post
Share on other sites
> Then, young one, you learn the preferred way of debugging: The method of printf()!
heh, what - are we coding Linux?

quote:
What if it happens only when you walk your charcter a few steps, and it doesnt happen after a certain amount of times but after some unknown time?

Then you realize it would be a good idea to implement deterministic playback in your engine.

Share this post


Link to post
Share on other sites
Actually, in the old days (or so my mummy tells me) they had assembly debuggers that actually ran the processor backwards for a few steps. Literally. I reckon a similar last-few-states type thing would be practical these days - sure, you''d get a performance hit, maybe even an 80% or 90% one, but if you only have to run your code once to find out what happened to it...

Anyway, if you''re suggesting that that manual debugging stuff is all in the past, what do you use for Java? I dislike command-based debugging more than printfs - do any IDEs (apart from VJ++) have decent debuggery? Been out of the java scene for a year or so now...

Share this post


Link to post
Share on other sites
Heh, debuggery sounds like an especially good curse.

To answer your question, Eclipse has a very good debugger. Arguably better than the VS6 one (not used VS.net so I can''t compare). I''ve not tried the C++ modules for it though, so they''re probably somewhat further behind.

Share this post


Link to post
Share on other sites
Cool, thanks! Downloading Eclipse now... all in aid of starting a new project, in Java, and realising that I haven't installed any java tools on my new computer. A decent IDE will make a nice change from gvim + cmd.exe

[edit: finished downloading Eclipse... wow! This is just like Visual J++, except without the crappy! :]

[edit again: oh god, I love it, I LOVE IT! Why didn't anyone *tell* me about this before? Eclipse is the coolest thing I have seen all... well... in a long long time. From using it for twenty minutes, I like it better than VC++ 6, and I like NOTHING better than VC++ 6. Thank you so much, OrangyTang, I'm forever in your debt!]

[edited by - fractoid on March 8, 2004 9:04:26 AM]

[edited by - fractoid on March 8, 2004 9:27:55 AM]

Share this post


Link to post
Share on other sites
how could you ever step back memory allocations, file reads and writes, constructors and destructors? It would require a HUGE memory space to do this and would run very slow (everything would have to be copied every instuction). Also then when you stepped back the entire memory space would have to be copied into the exact layout it was before which is comepltely unrealistic.

My advice would be to learn how to use an existing debugger properly before proposing ridiculous ideas like this.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
This is not easy to do with current debugging techniques on Win32/64. But you can use the SetUnhandledExceptionFilter function to set a trap for catching the untrapped exception. Save the stack information, compare with MAP and the symbolic debug information file and you have the entire state of the system on the moment of crash.
If you want it ''live'', you can create your own little debug program (not that hard) and have it debug your game - this way you can break down to the offending source code line when stuff happens (again with the use of map and symbol files) and do whatever it is that current debug programs can''t do.
As someone said then reverting to a previous state is probably only realistic if you program in ''simple'' or managed languages (asm, c or perhaps ilasm) - trying to revert state in a c++ program with multiple threads and the like is probably not realistic.
I have, personally, never needed to revert state to find a bug and I find the current debugging techniques quite adequate - check out John Robbins'' Debugging Applications for MS .NET and MS Windows - it is the tome to have for debugging Win32.

Share this post


Link to post
Share on other sites

  • Advertisement