用gdb调试:为什么这个= 0x0? [英] 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();

}

对象pCallStub调用功能addCallContext(pCallStub被实例化，而不是NULL).当我打印pCallStub时，我可以看到它有一个地址:

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

，但this(应为pCallStub)仍然是0x0:

(gdb) print this
    $2 = (globalCallStubClass * const) 0x0

有人可以帮助我吗?

谢谢， 赫塔

推荐答案

(gdb) print pCallStub
$1 = (globalCallStubClass *) **0x7a1da8**

(gdb) print this
$2 = (globalCallStubClass * const) **0x0**

您需要显示更多代码以帮助我们理解您的问题. 这里没有上下文，我们可以看到此== pCallStub的位置 另外，如果您启用了优化功能，则可能看不到您所看到的内容(例如，编译器优化了函数调用和堆栈，因此gdb不会报告正确的变量，因为它在堆栈上进行搜索.)在x86系统上，您会在ecx寄存器中找到"this".

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.

这篇关于用gdb调试:为什么这个= 0x0?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！