I use C++ 11 features actively. I have program created in Visual Studio 2013 that relies on lambdas to run multiple threads (lambda represents task, and thread receives lambda instance that it has to run). Lambda is defined in static library and linked in executable file that calls it from thread created by this executable file.
When I try to debug Linux version of this application with GDB, it looks like GDB can not step into method that contains lambda. It can not set breakpoints in this function, and when I try to step into, it even steps in methods that lambda calls from its body, but after return from these methods it doesn't go to lambda body, it goes to next method that lambda calls, etc.
Are there any way to debug lambdas body with GDB?
I've seen them in stack traces before, so it does at least know about them. I've never tried setting a normal breakpoint in one. It's sort of a hack, but you can set a breakpoint in one (or anywhere) by using asm volatile("int $3"); on x86(-64).
Here's an example program:
int main(){
auto f = [](){
asm volatile("int $3");
};
f();
return 0;
}
Here's it's backtrace when it hits that breakpoint:
#0 0x0000000000400577 in main::{lambda()#1}::operator()() const ()
#1 0x000000000040058d in main ()
From my experience, gdb cannot step into lambdas -- it just skips over them. Not only that, stepping into a lambda definition seems to confuse gdb and it proceeds to the end of the current function. You can, however, place a breakpoint explicitly inside a lambda, and if you hit that point, you will stop. This is obviously far from ideal.
Step into Lamba's .run() go next/step (jump initializations) until the following call:
std::forward<>(args)(...)
Step into this one. It will lead you to you lambda body code.
Related
I have a function with multiple return statements. I want to stop execution of my program (during debugging) when a return statement is about to be executed within this function.
One way to do this is add break points at all the return statements, but is there another way?
The closest you can do to a break-on-any-return is a step-out (shift+f11) from an existing breakpoint in the function. This won't let you inspect arguments to the return expression but it will let you inspect the value that is actually returned to the calling function. If you need to break from a running program then you are stuck needing to add breakpoints (either using the IDE or by calling DebugBreak() (or _CrtDbgBreak() if you want them to disappear from release builds).
Chances are there will be a single return generated in assembler. If you open up the assemble window and find the function exit, you should be able to stick a break point there.
For example:
dprintf main,"hello\n"
run
Generates the same output as:
break main
commands
silent
printf "hello\n"
continue
end
run
Is there a significant advantage to using dprintf over commands, e.g. it is considerably faster (if so why?), or has some different functionality?
I imagine that dprinf could be in theory faster as it could in theory compile and inject code with a mechanism analogous to the compile code GDB command.
Or is it mostly a convenience command?
Source
In the 7.9.1 source, breakpoint.c:dprintf_command, which defines dprintf, calls create_breakpoint which is also what break_command calls, so they both seem to use the same underlying mechanism.
The main difference is that dprintf passes the dprintf_breakpoint_ops structure, which has different callbacks and gets initialized at initialize_breakpoint_ops.
dprintf stores list of command strings much like that of commands command, depending on the settings. They are:
set at update_dprintf_command_list
which gets called on after a type == bp_dprintf check inside init_breakpoint_sal
which gets called by create_breakpoint.
When a breakpoint is reached:
bpstat_stop_status gets called and invokes b->ops->after_condition_true (bs); for the breakpoint reached
after_condition_true for dprintf is dprintf_after_condition_true
bpstat_do_actions_1 runs the commands
There are two main differences.
First, dprintf has some additional output modes that can be used to make it work in other ways. See help set dprintf-channel, or the manual, for more information. I think these modes are the reason that dprintf was added as a separate entity; though at the same time they are fairly specialized and unlikely to be of general interest.
More usefully, though, dprintf doesn't interfere with next. If you write a breakpoint and use commands, and then next over such a breakpoint, gdb will forget about the next and act as if you had typed continue. This is a longstanding oddity in the gdb scripting language. dprintf doesn't suffer from this problem. (If you need similar functionality from an ordinary breakpoint, you can do this from Python.)
That one surprised me, when doing tab for auto complete for a breakpoint it appeared two options to the same method.
test::TestFoo::SendFoo(short)
test::TestFoo::SendFoo(short)::fooID
On cpp:
bool TestFoo::SendFoo( short x )
{
...
static unsigned int fooID = 0;
Why gdb differs? what's the benefit of using one or another?
Question tagged as C++ to avoid any missunderstanding from C static.
gdb --version
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-56.el6)
...
SendFoo::fooID and SendFoo are two different kinds of symbols, and I can imagine there will be a difference in the two breakpoints gdb offers you - although I am not very familiar with it:
The line where fooID is defined/initialized will be only hit once in the whole program, so a breakpoint in that line should be hit only once as well. A function level breakpoint should be hit every time the function gets called, so there is a major difference.
AFAIK the function scope static means the same for both C and C++ - a variable that is shared between all calls of that function and initialized the first time the function gets called.
I have a third part library function call scattered at a lot of places in my executable. My executable is built using debug symbols, but the third party library does not have the debug symbols, hence I cannot place a breakpoint on the function. I want to put a breakpoint whenever the library function is called, to examine the call stack.
How can I set a breakpoint at all invocations of a library function call within my executable.
I think that the only way is to:
find any call of this function in your code;
create a breakpoint in that line;
run the debugger and stop there;
write in gdb nexti to get to the first function instruction;
get current eip which will point at the beginning of that function;
create a new breakpoint at the address pointed by eip;
I have found myself in this situation many times where I need to break into a function that is called hundreds of times only after a particular break-point has been hit.
So let's say there is a function that updates the status of objects. This is called multiple times per
frame. I am testing a function that edits an object. As soon as that function is hit, I can then break into the UpdateStatus function. Obviously, if I put a breakpoint in UpdateStatus it will always break and I will never be able to interact with the program. What would be great if I could set a condition on the breakpoint to only break if the breakpoint in the other function hit. Note that this is just an example.
I am using Visual C++ 2008.
I remember running into a situation like this myself. I believe you can combine Visual Studio tracepoints with Visual Studio macros to do this pretty easily. This page describes how to write a macro that turns on breakpoints: http://weseetips.com/tag/enable-breakpoint/ Since you want to enable only a single breakpoint, you'll want to use some combination of file and line number in your macro to enable only the breakpoint you want--you can find the breakpoint object members here: http://msdn.microsoft.com/en-us/library/envdte.breakpoint.aspx (File and FileLine look particularly useful)
This page describes how to use a 'tracepoint' to run a macro: http://msdn.microsoft.com/en-us/library/232dxah7.aspx (This page has some nice screenshots of setting up tracepoints: http://weblogs.asp.net/scottgu/archive/2010/08/18/debugging-tips-with-visual-studio-2010.aspx in VS2010)
So you could create a macro that will enable your breakpoint, and create a tracepoint that executes your macro. (You can even add a second tracepoint that disables the breakpoint afterward, so that you can easily repeat the process.)
You might be able to place a conditional breakpoint within the UpdateStatus itself.
Alternatively, place a conditional breakpoint at the call-site of UpdateStatus then perform the step-in manually.
Whether you'll be able to do one or the other (or any at all) depends on how complex the breakpoint condition is and whether input for that condition is "reachable" from the particular stack frame.
You could have the first breakpoint set a flag when hit, then let the second breakpoint check that flag as a condition.
You can set the flag by specifying a "message" to be printed when hit, like so:
{flag = 1;}
flag needs to exist in the scope, of course.
(It would be nice if it was possible to declare a variable that only exists during the debug, but I'm unaware of how to do this.)