debugging with gdb: why this=0x0? - gdb

I'm using gdb for debugging a program. And what I see is kind of strange:
(gdb) bt
0xb59656f8 in globalCallStubClass::addCallContext (**this=0x0**)
at /ccase_enodeb/callp/build_callp/src/test/framework/shared/src/shared_call_context.cc:1962
0xb5b52e64 in rrcStubClass::process_scenario_spontaneous_trigger_RRC_CONNECTION_REQUEST (gcppMsgCtx=...)
at /ccase_enodeb/callp/build_callp/src/test/framework/rrc/src/rrc_connection_request.cc:90
0xb6c3be4c in Gcpp::routeMessage (this=0xb392e9d0) at /ccase_enodeb/callp/build_callp/src/callp_services/gcpp/src/gcpp.cc:1095
0xb6c3b3b0 in Gcpp::loop (this=0xb392e9d0, Default_Method_Ptr=0)
at /ccase_enodeb/callp/build_callp/src/callp_services/gcpp/src/gcpp.cc:925
0xb58d2ae0 in stubBthdEntryPoint () at /ccase_enodeb/callp/build_callp/src/test/framework/root/src/stub_root.cc:314
0x000191f8 in lxb_thd_entry (pCtx=0x68c0f8) at /vobs/onepltf/ltefdd/core/src/lxbase/lxbase.c:3289
0xb575602e in start_thread () from /lib/arm-linux-gnueabi/libpthread.so.0
0xb56d6ab8 in ?? () from /lib/arm-linux-gnueabi/libc.so.6
0xb56d6ab8 in ?? () from /lib/arm-linux-gnueabi/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) print pCallStub
$1 = (globalCallStubClass *) **0x7a1da8**
(gdb) print this
$2 = (globalCallStubClass * const) **0x0**
The chrash appears at line marked with (-->):
if (pCallStub != NULL) {
-->callStubClass* pCallInst = pCallStub->addCallContext();
}
Function addCallContext is called for object pCallStub (pCallStub is instantiated and is not NULL). When I print pCallStub I can see that it has an address:
(gdb) print pCallStub
$1 = (globalCallStubClass *) 0x7a1da8
but still, this (which should be pCallStub) is 0x0:
(gdb) print this
$2 = (globalCallStubClass * const) 0x0
Can anyone help me?
Thanks,
Geta

pCallStub is 0x0, so it's pointing to NULL. You have to instantiate an object with pCallStub = new globalCallStubClass() or a creator function like pCallStub = createGlobalCallStubClass() before using the pointer.

(gdb) print pCallStub
$1 = (globalCallStubClass *) **0x7a1da8**
(gdb) print this
$2 = (globalCallStubClass * const) **0x0**
You need to show more code for us to understand your issue.
There is no context here where we could see where this == pCallStub
Also, if you have optimizations turned on, you might not see what you think you're seeing (like the compiler optimized the function call and the stack so gdb doesn't report the right variable because it search it on the stack. Typically, on a x86 system, you'll find "this" in ecx register.
Since you have multiple thread you can have the "multithread singleton issue", that is, one thread is allocating and storing in the singleton instance, but other thread don't see it yet.
Try to use atomic compare and swap to set the singleton instance for example.

Related

Writing an efficient backtrace function

I came across below code for walking backtrace
struct stack_frame {
struct stack_frame *prev;
void *return_addr;
} __attribute__((packed));
typedef struct stack_frame stack_frame;
__attribute__((noinline, noclone))
void backtrace_from_fp(void **buf, int size)
{
int i;
stack_frame *fp;
__asm__("movl %%ebp, %[fp]" : /* output */ [fp] "=r" (fp));
for(i = 0; i < size && fp != NULL; fp = fp->prev, i++)
buf[i] = fp->return_addr;
}
the reason behind looking for this code is we are using a 3rd party malloc hook hence don't want to use backtrace which again allocates memory. Above doesn't work for x86_64 and I modified asm statement to
__asm__("movl %%rbp, %[fp]" : /* output */ [fp] "=r" (fp));
I get crash
(gdb) bt
#0 backtrace_from_fp (size=10, buf=<optimized out>) at src/tcmalloc.cc:1910
#1 tc_malloc (size=<optimized out>) at src/tcmalloc.cc:1920
#2 0x00007f5023ade58d in __fopen_internal () from /lib64/libc.so.6
#3 0x00007f501e687956 in selinuxfs_exists () from /lib64/libselinux.so.1
#4 0x00007f501e67fc28 in init_lib () from /lib64/libselinux.so.1
#5 0x00007f5029a32503 in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#6 0x00007f5029a241aa in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#7 0x0000000000000001 in ?? ()
#8 0x00007fff22cb8e24 in ?? ()
#9 0x0000000000000000 in ?? ()
(gdb)
(gdb) p $rbp
$2 = (void *) 0x7f501e695f37
(gdb) p (stack_frame *)$rbp
$3 = (stack_frame *) 0x7f501e695f37
(gdb) p *$3
$4 = {prev = 0x69662f636f72702f, return_addr = 0x6d6574737973656c}
(gdb) x /1xw 0x69662f636f72702f
0x69662f636f72702f: Cannot access memory at address 0x69662f636f72702f
(gdb) fr
#0 backtrace_from_fp (size=10, buf=<optimized out>) at src/tcmalloc.cc:1910
1910 in src/tcmalloc.cc
(gdb)
Am I missing something ?. Any help on how can I reconstruct the same via code ?.
Am I missing something ?
The code you referenced assumes the compiled code is using frame pointer register chain.
This was the default on (32-bit) i*86 up until about 5-7 years ago, and has not been the default on x86_64 since ~forever.
The code will most likely work fine in non-optimized builds, but will fail miserably with optimization on both 32-bit and 64-bit x86 platforms using non-ancient versions of the compiler.
If you can rebuild all code (including libc) with -fno-omit-frame-pointer, then this code will work most of the time (but not all the time, because libc may have hand-coded assembly, and that assembly will not have frame pointer chain).
One solution is to use libunwind. Unfortunately, using it from inside malloc can still run into a problem, if you (or any libraries you use) also use dlopen.

sigsegv during __gcc_register_frame (mingw32)

I try to debug crash (sigsegv especially) of application that uses dynamic libraries (.dll). As I can see it crashes in statically linked part of code in library initialization. GDB shows something similar to (addresses are changing):
Program received signal SIGSEGV, Segmentation fault.
0x00e41290 in __gcc_register_frame ()
from library.dll
1: x/5i $pc
=> 0xe41290 <__gcc_register_frame+208>: movl $0xebc6f0,0x11f2000
0xe4129a <__gcc_register_frame+218>: mov $0xebc2b0,%esi
0xe4129f <__gcc_register_frame+223>: jmp 0xe41222 <__gcc_register_frame+98>
0xe412a1 <__gcc_register_frame+225>: jmp 0xe412b0 <__gcc_deregister_frame>
During the same session I can see that 0x11f2000 is correct part of library.dll
(gdb) info symbol 0x11f2000
deregister_frame_fn in section .data of library.dll
Mentioned address space is available from GDB, so setting/reading values is possible:
(gdb) print (unsigned char*)0x11f2000
$1 = (unsigned char *) 0x11f2000 <deregister_frame_fn> ""
(gdb) set *(unsigned char*)0x11f2000=1
(gdb) set *(unsigned char*)0x11f2001=2
(gdb) set *(unsigned char*)0x11f2002=3
(gdb) set *(unsigned char*)0x11f2003=4
(gdb) print (unsigned char*)0x11f2000
$2 = (unsigned char *) 0x11f2000 <deregister_frame_fn> "\001\002\003\004"
I wonder I'm not able to make short example in cpp, since another library we use in the same application (with the same compiler) is working fine.
The main question is why there may be crash like sigsegv if memory location is available in gdb?
gcc version 5.2.0 (Sourcery CodeBench)
Below backtrace:
(gdb) bt
#0 0x00e41290 in __gcc_register_frame ()
from library.dll
#1 0x00eb7afa in __do_global_ctors ()
from library.dll
#2 0x00e4110b in DllMainCRTStartup#12 ()
from library.dll
...

How to step into a set of chained methods with gdb? [duplicate]

I am debugging C++ in gdb 7.1 on Linux.
I have a function a() that is called in many places in the code. I want to set a breakpoint in it, but only if it was called from b(). Is there any way to do it?
Is there any way to do it only if b() was called from c(), and so on ad infinitum?
Update: There is now a better answer to this question: use GDB _is_caller convenience function.
The need you describe comes up quite often, usually in the context of some_utility_fn being called a lot, but you only are interested in the call which comes from some_other_fn.
You could probably script this entire interaction using the new embedded Python support in GDB from CVS trunk.
Without Python, you are limited in what you can do, but the usual technique is to have a disabled breakpoint on a(), and enable it from a command, attached to a breakpoint on b().
Here is an example:
int a(int x)
{
return x + 1;
}
int b()
{
return a(1);
}
int call_a_lots()
{
int i, sum = 0;
for (i = 0; i < 100; i++)
sum += a(i);
}
int main()
{
call_a_lots();
return b();
}
gcc -g t.c
gdb -q ./a.out
Reading symbols from /tmp/a.out...done.
(gdb) break a
Breakpoint 1 at 0x4004cb: file t.c, line 3.
(gdb) disable 1
(gdb) break b
Breakpoint 2 at 0x4004d7: file t.c, line 8.
(gdb) command 2
>silent
>enable 1
>continue
>end
(gdb) run
Breakpoint 1, a (x=1) at t.c:3
3 return x + 1;
(gdb) bt
#0 a (x=1) at t.c:3
#1 0x00000000004004e1 in b () at t.c:8
#2 0x000000000040052c in main () at t.c:21
(gdb) q
Voila: we've stopped on a() called from b(), ignoring previous 100 calls to a().
gdb can handle this directly now without any need for Python. Just do this:
b a if $_caller_is("b")
I have tested this on gdb 7.6 that is already available but it does not work on gdb 7.2 and probably on gdb 7.1:
So this is main.cpp:
int a()
{
int p = 0;
p = p +1;
return p;
}
int b()
{
return a();
}
int c()
{
return a();
}
int main()
{
c();
b();
a();
return 0;
}
Then g++ -g main.cpp
This is my_check.py:
class MyBreakpoint (gdb.Breakpoint):
def stop (self):
if gdb.selected_frame().older().name()=="b":
gdb.execute("bt")
return True
else:
return False
MyBreakpoint("a")
And this is how it works:
4>gdb -q -x my_check.py ./a.out
Reading symbols from /home/a.out...done.
Breakpoint 1 at 0x400540: file main.cpp, line 3.
(gdb) r
Starting program: /home/a.out
#0 a () at main.cpp:3
#1 0x0000000000400559 in b () at main.cpp:10
#2 0x0000000000400574 in main () at main.cpp:21
Breakpoint 1, a () at main.cpp:3
3 int p = 0;
(gdb) c
Continuing.
[Inferior 1 (process 16739) exited normally]
(gdb) quit
A simpler solution than Python scripting is using a temporary breakpoint.
It looks like this:
b ParentFunction
command 1
tb FunctionImInterestedIn
c
end
Every time you break in ParentFunction, you'll set a one-time breakpoint on the function you're actually interested in, then continue running (presumably until you hit that breakpoint).
Since you'll break exactly once on FunctionImInterestedIn, this won't work if FunctionImInterestedIn is called multiple times in the context of ParentFunction and you want to break on each invocation.
not sure how to do it by gdb.
But you can declare global variable like:
bool call_a = false;
and when b calling a
call_a = true;
a();
and set call_a to false when other function call a() or after your breakpoint
then use condition break-point
break [line-number] if call_a == true
An easy one for arm is:
Set the breakpoint in the function you are interested.
break a
Attach an gdb command to that breakpoint.
command 1
up 1
if $lr == 0x12345678
echo match \n
down 1
else
echo no match \n
echo $lr \n
down 1
cont
end
end
When ever you arrive in the function a(), the command temporarily pops up one stack frame thus updating the link register. The callers link register value can then be used continue when the caller is not the execution
path you need.
Enjoy.

does gdb has something similar to struct command of crash utility

I want to dump the internal data structures of ovs-vswitchd.
(gdb) print/x all_dpif_backers
$11 = {
map = {
buckets = 0x7e0e28,
one = 0x23467f0,
mask = 0x0,
n = 0x1
}
}
Now I know 0x23467f0 is the address of struct hmap_node. If using crash
utility, I can dump the value like this:
crash> struct hmap_node 0x23467f0
How can we do this using gdb?
How can we do this using gdb?
(gdb) print *(struct hmap_node*) 0x23467f0
Or
(gdb) print (struct hmap_node*) 0x23467f0
$1 = ...
(gdb) print *$1
See also GDB pretty printing.

Is there any way to set a breakpoint in gdb that is conditional on the call stack?

I am debugging C++ in gdb 7.1 on Linux.
I have a function a() that is called in many places in the code. I want to set a breakpoint in it, but only if it was called from b(). Is there any way to do it?
Is there any way to do it only if b() was called from c(), and so on ad infinitum?
Update: There is now a better answer to this question: use GDB _is_caller convenience function.
The need you describe comes up quite often, usually in the context of some_utility_fn being called a lot, but you only are interested in the call which comes from some_other_fn.
You could probably script this entire interaction using the new embedded Python support in GDB from CVS trunk.
Without Python, you are limited in what you can do, but the usual technique is to have a disabled breakpoint on a(), and enable it from a command, attached to a breakpoint on b().
Here is an example:
int a(int x)
{
return x + 1;
}
int b()
{
return a(1);
}
int call_a_lots()
{
int i, sum = 0;
for (i = 0; i < 100; i++)
sum += a(i);
}
int main()
{
call_a_lots();
return b();
}
gcc -g t.c
gdb -q ./a.out
Reading symbols from /tmp/a.out...done.
(gdb) break a
Breakpoint 1 at 0x4004cb: file t.c, line 3.
(gdb) disable 1
(gdb) break b
Breakpoint 2 at 0x4004d7: file t.c, line 8.
(gdb) command 2
>silent
>enable 1
>continue
>end
(gdb) run
Breakpoint 1, a (x=1) at t.c:3
3 return x + 1;
(gdb) bt
#0 a (x=1) at t.c:3
#1 0x00000000004004e1 in b () at t.c:8
#2 0x000000000040052c in main () at t.c:21
(gdb) q
Voila: we've stopped on a() called from b(), ignoring previous 100 calls to a().
gdb can handle this directly now without any need for Python. Just do this:
b a if $_caller_is("b")
I have tested this on gdb 7.6 that is already available but it does not work on gdb 7.2 and probably on gdb 7.1:
So this is main.cpp:
int a()
{
int p = 0;
p = p +1;
return p;
}
int b()
{
return a();
}
int c()
{
return a();
}
int main()
{
c();
b();
a();
return 0;
}
Then g++ -g main.cpp
This is my_check.py:
class MyBreakpoint (gdb.Breakpoint):
def stop (self):
if gdb.selected_frame().older().name()=="b":
gdb.execute("bt")
return True
else:
return False
MyBreakpoint("a")
And this is how it works:
4>gdb -q -x my_check.py ./a.out
Reading symbols from /home/a.out...done.
Breakpoint 1 at 0x400540: file main.cpp, line 3.
(gdb) r
Starting program: /home/a.out
#0 a () at main.cpp:3
#1 0x0000000000400559 in b () at main.cpp:10
#2 0x0000000000400574 in main () at main.cpp:21
Breakpoint 1, a () at main.cpp:3
3 int p = 0;
(gdb) c
Continuing.
[Inferior 1 (process 16739) exited normally]
(gdb) quit
A simpler solution than Python scripting is using a temporary breakpoint.
It looks like this:
b ParentFunction
command 1
tb FunctionImInterestedIn
c
end
Every time you break in ParentFunction, you'll set a one-time breakpoint on the function you're actually interested in, then continue running (presumably until you hit that breakpoint).
Since you'll break exactly once on FunctionImInterestedIn, this won't work if FunctionImInterestedIn is called multiple times in the context of ParentFunction and you want to break on each invocation.
not sure how to do it by gdb.
But you can declare global variable like:
bool call_a = false;
and when b calling a
call_a = true;
a();
and set call_a to false when other function call a() or after your breakpoint
then use condition break-point
break [line-number] if call_a == true
An easy one for arm is:
Set the breakpoint in the function you are interested.
break a
Attach an gdb command to that breakpoint.
command 1
up 1
if $lr == 0x12345678
echo match \n
down 1
else
echo no match \n
echo $lr \n
down 1
cont
end
end
When ever you arrive in the function a(), the command temporarily pops up one stack frame thus updating the link register. The callers link register value can then be used continue when the caller is not the execution
path you need.
Enjoy.