如何定位死机问题

如果trace长时间卡在某处，可能出现了死循环，可使用命令pstackpidofgbased 来看当前gbased堆栈，若一直卡在某个函数，就可能出现了死循环，还可通过 show table locks 来看当前锁状态， 排除死锁。

如果出现了死机现象，会在与执行日志相同目录的 /opt/gnode/log/gbase/system.log里打印当前的堆栈

/opt/gnode/log/gbase/system.log

QAttemptingbacktrace. You can use the following information to find out

wheregbased died. If you see no messages after this, something went

terribly wrong...

stack_bottom = 0x7f85d0477958 thread_stack 0x40000

/opt/gnode/server/bin/gbased(my_print_stacktrace+0x35)[0x103ee65]

/opt/gnode/server/bin/gbased(handle_segfault+0x4ab)[0x67ddfb]

/lib64/libpthread.so.0[0x3241c0f710]

/opt/gnode/server/bin/gbased(_ZN6PAAttr13GetValueInt64EyP3BSI+0x9a)[0xc0292a]

/opt/gnode/server/bin/gbased(_ZN9TempTable11FillOnePageEP3THDR11MDFIteratorxxxbPSt6vectorIP16LogicalAttributeSaIS6_EE+0x34d)[0xe72add]

/opt/gnode/server/bin/gbased(_ZN9TempTable23FillMaterializedBuffersEyybbP12ResultSenderbPNS_4AttrE+0x1a2e)[0xe7b67e]

/opt/gnode/server/bin/gbased(_ZN9TempTable11MaterializeEbP3THDP13select_resultP12ResultSender+0x109c)[0xb5f7ec]

...

thd->query at xxx   列出sql语句

对system.log格式化后的trace： (cat system.log | c++filt)

stack_bottom = 0x7f85d0477958 thread_stack 0x40000

/opt/gnode/server/bin/gbased(my_print_stacktrace+0x35)[0x103ee65]

/opt/gnode/server/bin/gbased(handle_segfault+0x4ab)[0x67ddfb]

/lib64/libpthread.so.0[0x3241c0f710]

/opt/gnode/server/bin/gbased(PAAttr::GetValueInt64(unsigned long long, BSI*)+0x9a)[0xc0292a]

/opt/gnode/server/bin/gbased(TempTable::FillOnePage(THD*, MDFIterator&, long long, long long, long long, bool, std::vector<LogicalAttribute*, std::allocator<LogicalAttribute*>>*)+0x34d)[0xe72add]

/opt/gnode/server/bin/gbased(TempTable::FillMaterializedBuffers(unsigned long long, unsigned long long, bool, bool, ResultSender*, bool, TempTable::Attr*)+0x1a2e)[0xe7b67e]

PAAttr::GetValueInt64是死机前最后一个函数，他在整个程序中的地址在0xc0292a， 在这个函数内偏移0x9a地址处

如果是debug版可直接 addr2line -e /opt/gnode/server/bin/gbased 0xc0292a 得到具体行数

如果是release版可以对gbased执行objdump成汇编，找到地址对应的行数