Jump to content
  • Advertisement

Archived

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

Drazgal

Using _asm{int 3}

This topic is 5275 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

As far as I know I can use this inline assembly in my code to set a break point (for writting custom asserts and error code). Works great when I run the program in debug (Im using Visual C++ 6.0 with latest service pack and processor pack), however when I run the program normally instead of ignoring the breakpoint as I was expecting the program to do (as it does when I set breakpoints in the IDE) I get a critical error. I ran both times with debug as my active config. Is there anyway around this or if I want to use this am I just going to have to run in debug forever and use the preprocessor to remove it for release build?

Share this post


Link to post
Share on other sites
Advertisement
"int 3" is just an x86 CPU interrupt/exception that''s commonly reserved for use as a breakpoint.

The debugger works by implementing an "exception handler" that gets called when the interrupt/exception is processed by the CPU. The debugger does clever stuff like looking up the file and line number of the source code file using any debug information from compilation time (*.pdb, *.sym etc) as well as being able to find the next line of code and execute that if you "continue" past the breakpoint.

When you''re not running inside a debugger, if you haven''t written your own system exception handler, when the CPU hits that "int3", it jumps to the standard Windows system exception processing which displays the "Unhandled Exception"/critical error message.


You shouldn''t have any int 3''s in your release builds. They should always be wrapped in a #ifdef DEBUG. The best thing to do is make the "_asm int3" itself a macro which dissolves to nothing in release builds, e.g.:

#ifdef DEBUG
#define BREAKPOINT __asm int3
#else
#define BREAKPOINT
#endif

And then just use the macro anywhere you want that int3


Funnily enough, Microsoft have already done that for you, and in a way that will work on non x86 CPUs and will also be automatically updated for new CPUS:

Anywhere you''d use __asm int3, use "_CrtDbgBreak()" instead (it''s in the "crtdbg.h" header)


Simon O''Connor
Game Programmer &
Microsoft DirectX MVP

Share this post


Link to post
Share on other sites
Is there anyway around this ?

Register an interrupt handler for it? (hint - you really don''t want to do that.)


or if I want to use this am I just going to have to run in debug forever and use the preprocessor to remove it for release build?

Precisely. What in hell are you have hard-coding breakpoints for, anyway?


“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
— Brian W. Kernighan

Share this post


Link to post
Share on other sites
quote:
Original post by Fruny
Is there anyway around this ?

Register an interrupt handler for it? (hint - you really don''t want to do that.)


or if I want to use this am I just going to have to run in debug forever and use the preprocessor to remove it for release build?

Precisely. What in hell are you have hard-coding breakpoints for, anyway?


“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
— Brian W. Kernighan



I agree. Why are you hard coding breakpoints?

Patient: "Doctor, it hurts when I do that."
Doctor: "Then don''t do that."

Share this post


Link to post
Share on other sites
Thanks for the replies!

I want to hardcode breakpoints for custom assert macros in my code. Such as displaying the stack, writting to the log file etc.

Hmm with crtdbg.h I still have the same problem. I might not have explained my problem clearly.

The hardcoded breakpoints I currently have are in asserts and so dispear in release mode, so there is not a problem. However they breakpoints are there in debug mode.

My problem is that I get a critical error when I run the program (ctrl-F5 for visual studios c++ 6.0) or from the command line instead of runing it through the debugger (F5). This happens with _CrtDbgBreak(), _asm{int 3} and DebugBreak() in both Win32 and Win16.

[edited by - Drazgal on June 5, 2004 9:16:09 PM]

Share this post


Link to post
Share on other sites

My problem is that I get a critical error when I run the program (ctrl-F5 for visual studios c++ 6.0) or from the command line instead of runing it through the debugger (F5). This happens with _CrtDbgBreak(), _asm{int 3} and DebugBreak() in both Win32 and Win16.


You''ll get the error whenever a debugger is not attached to the process. Short of mucking with the interrupt vector yourself, there is no workaround. Live with it.


“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
— Brian W. Kernighan

Share this post


Link to post
Share on other sites
Thanks for the replies found the answer though

http://www.flipcode.com/cgi-bin/msg.cgi?showThread=Tip-ProgramTriggeredBreakpoints&forum=totd&id=-1

Share this post


Link to post
Share on other sites
quote:
Original post by Drazgal
Thanks for the replies found the answer though

http://www.flipcode.com/cgi-bin/msg.cgi?showThread=Tip-ProgramTriggeredBreakpoints&forum=totd&id=-1


Aha, so your issue was about running debug builds of your program without a debugger attached and wanting to use breakpoints for things other than break -points .

Glad you found one of a couple of solutions (either write a dummy exception handler that skips the breakpoint or use IsDebuggerPresent() to check if your code is running inside a debugger).


[edited by - s1ca on June 5, 2004 10:03:44 PM]

Share this post


Link to post
Share on other sites
Yeah on a reread of my post its not very clear. I blame it being 2:30am where I was when I posted Hmmm IsDebuggerPresent() that works even better (I have no idea how I missed seeing that in MSDN).

Thanks!!

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!