Run an Application in Gdb Until an Exception Occurs

Run an Application in GDB Until an Exception Occurs

You can try using a "catchpoint" (catch throw) to stop the debugger at the point where the exception is generated.

The following excerpt From the gdb manual describes the catchpoint feature.

---

5.1.3 Setting catchpoints

You can use catchpoints to cause the debugger to stop for certain kinds of program events, such as C++ exceptions or the loading of a shared library. Use the catch command to set a catchpoint.

• catch event

  Stop when event occurs. event can be any of the following:

  • throw

    The throwing of a C++ exception.

  • catch

    The catching of a C++ exception.

  • exec

    A call to exec. This is currently only available for HP-UX.

  • fork

    A call to fork. This is currently only available for HP-UX.

  • vfork

    A call to vfork. This is currently only available for HP-UX.

  • load or load libname

    The dynamic loading of any shared library, or the loading of the library libname. This is currently only available for HP-UX.

  • unload or unload libname

    The unloading of any dynamically loaded shared library, or the unloading of the library libname. This is currently only available for HP-UX.

• tcatch event

  Set a catchpoint that is enabled only for one stop. The catchpoint is automatically deleted after the first time the event is caught.

Use the info break command to list the current catchpoints.

There are currently some limitations to C++ exception handling (catch throw and catch catch) in GDB:

• If you call a function interactively, GDB normally returns control to you when the function has finished executing. If the call raises an exception, however, the call may bypass the mechanism that returns control to you and cause your program either to abort or to simply continue running until it hits a breakpoint, catches a signal that GDB is listening for, or exits. This is the case even if you set a catchpoint for the exception; catchpoints on exceptions are disabled within interactive calls.

• You cannot raise an exception interactively.

• You cannot install an exception handler interactively.

Sometimes catch is not the best way to debug exception handling: if you need to know exactly where an exception is raised, it is better to stop before the exception handler is called, since that way you can see the stack before any unwinding takes place. If you set a breakpoint in an exception handler instead, it may not be easy to find out where the exception was raised.

To stop just before an exception handler is called, you need some knowledge of the implementation. In the case of GNU C++, exceptions are raised by calling a library function named __raise_exception which has the following ANSI C interface:

/* addr is where the exception identifier is stored.
   id is the exception identifier.  */
void __raise_exception (void **addr, void *id);

To make the debugger catch all exceptions before any stack unwinding takes place, set a breakpoint on __raise_exception (see section Breakpoints; watchpoints; and exceptions).

With a conditional breakpoint (see section Break conditions) that depends on the value of id, you can stop your program when a specific exception is raised. You can use multiple conditional breakpoints to stop your program when any of a number of exceptions are raised.

Can gdb be set to break on any throw?

You can do this with the catch throw command. See here:

catch event

Stop when event occurs. The event can be any of the
following:

throw [regexp]

rethrow [regexp]

catch [regexp]

The throwing,
re-throwing, or catching of a C++ exception.

If regexp is given, then only exceptions whose type matches the
regular expression will be caught.

Specify a particular exception to stop GDB using catch

Since the exception is defined in my own program, the correct way to do this is to simply put a breakpoint in the constructor of the exception.

GDB: Re-run program until it faults, answering prompts along the way

Because you program reads its input from stdin, your task is straightforward. Simply create your input file as follows:

1
2
3
...

Then, your gdb command sequence changes its run phase to include the input file (say input.txt):

set pagination off
break exit
commands
run < input.txt
end

Is there an until command in gdb?

In addition to Michael's explanation of breakpoints, that are probably the best way to solve your problem, there are actually also are "until" and "advance" commands, that do just what you require/suggest.

Basically you can do "until 60" or "until main.c:60" or "advance 60" or similar, depending if you want to limit temporary breakpoint to current frame or not.

See appropriate section of GDB manual.

upon exception I would like debugging without any stack unwinding

You didn't specify your toolset/platform.

But in MSVC you can configure the debugger to break on various types of exceptions, in your case it would be C++ exceptions.

See here for details:

http://msdn.microsoft.com/en-us/library/d14azbfh.aspx

Edit: For gcc/gdb see this question Run an Application in GDB Until an Exception Occurs

How to turn all throws into abort conditions for debugging purposes?

It's trivial. The command is catch throw. Start gdb pointing it at your executable. Issue the catch throw command and then the run command.

---

Related Topics