在QNX中调试核心转储 - 如何获取更多信息？

Question

我以前的工作代码现在崩溃了。核心转储指向被调用的构造函数。 我试图得到bt，bt完整和反汇编。我需要一些帮助来确定在调用构造函数时可能导致分段错误的原因？ 代码在QNX上运行，并且只有控制台gdb。局部变量都是0，这意味着什么？

这里的O/P：拆卸的

(gdb) bt 
#0 0x481a95b0 in notifyDs3PathAlarmClrEvent__F9PATH_TYPEUi17DS3_PATH_ALARM_ID (path_Type=PATH_NULL, pathId=1215822164, 
    alarm_Id=DS3_PATH_IDLE_ID) at /vob/qnx/cema-common/msg/PathObjMsg.h:47 
(gdb) bt full 
#0 0x481a95b0 in notifyDs3PathAlarmClrEvent__F9PATH_TYPEUi17DS3_PATH_ALARM_ID (path_Type=PATH_NULL, pathId=1215822164, 
    alarm_Id=DS3_PATH_IDLE_ID) at /vob/qnx/cema-common/msg/PathObjMsg.h:47 
     msg = {<Message> = {msgSource = MSG_SOURCE_INVALID, msgPriority = MSG_PRIO_LOW, msgLength = 0}, 
    msgType = MSG_PATH_ALARM, pathType = PATH_NULL, pathId = {bay = 0 '\0', line = 0 '\0', path = {stsn = { 
     sts1Num = 0 '\0'}, vt = {sts1Num = 0 '\0', isTu3 = 0 '\0', tug3Num = 0 '\0', vtgTug2Num = 0 '\0', 
     vtTuNum = 0 '\0'}, ds3 = {sts1Num = 0 '\0', ds3Num = 0 '\0'}, ds1InDS3Line = {pad = 0 '\0', ds1Num = 0 '\0'}, 
     ds1InVT = {sts1Num = 0 '\0', pad = 0 '\0', tug3Num = 0 '\0', vtgTug2Num = 0 '\0', vtTuNum = 0 '\0'}, 
     ds1InDS3Path = {sts1Num = 0 '\0', tug3Num = 0 '\0', ds1Num = 0 '\0'}, e1InVT = {sts1Num = 0 '\0', pad = 0 '\0', 
     tug3Num = 0 '\0', vtgTug2Num = 0 '\0', vtTuNum = 0 '\0'}, e3 = {sts1Num = 0 '\0', ds3Num = 0 '\0'}}}, 
    alarmId = 0, lineId = 0 '\0'} 
     emPathType = PATH_NULL 
     emAlarmId = 10 

(gdb) l * 0x481a95b0 
0x481a95b0 is in notifyDs3PathAlarmClrEvent__F9PATH_TYPEUi17DS3_PATH_ALARM_ID (/vob/qnx/cema-common/msg/PathObjMsg.h:47). 

42   PathObjMsg(
43    PATH_TYPE pathTypeIn, 
44    EM_PATH_ID pathIdIn, 
45    PATH_OBJ_MSG_TYPE msgTypeIn, 
46    EM_PATH_ALARM_ID alarmIdIn 
**47   ): Message(MSG_SOURCE_PATH_OBJ)** 
48   { 
49    pathType = pathTypeIn; 
50    pathId = pathIdIn; 
51    msgType = msgTypeIn; 

O/P：现在

bne-  0x481a962c <notifyDs3PathAlarmClrEvent__F9PATH_TYPEUi17DS3_PATH_ALARM_ID+264> 
0x481a959c <notifyDs3PathAlarmClrEvent__F9PATH_TYPEUi17DS3_PATH_ALARM_ID+120>: li  r0,15 
0x481a95a0 <notifyDs3PathAlarmClrEvent__F9PATH_TYPEUi17DS3_PATH_ALARM_ID+124>: mr  r27,r28 
0x481a95a4 <notifyDs3PathAlarmClrEvent__F9PATH_TYPEUi17DS3_PATH_ALARM_ID+128>: stw  r27,88(r1) 
0x481a95a8 <notifyDs3PathAlarmClrEvent__F9PATH_TYPEUi17DS3_PATH_ALARM_ID+132>: stw  r0,8(r1) 
0x481a95ac <notifyDs3PathAlarmClrEvent__F9PATH_TYPEUi17DS3_PATH_ALARM_ID+136>: addi r31,r1,8 
0x481a95b0 <notifyDs3PathAlarmClrEvent__F9PATH_TYPEUi17DS3_PATH_ALARM_ID+140>: li  r9,1 
0x481a95b4 <notifyDs3PathAlarmClrEvent__F9PATH_TYPEUi17DS3_PATH_ALARM_ID+144>: stw  r9,4(r31) 
0x481a95b8 <notifyDs3PathAlarmClrEvent__F9PATH_TYPEUi17DS3_PATH_ALARM_ID+148>: stw  r29,16(r31) 
0x481a95bc <notifyDs3PathAlarmClrEvent__F9PATH_TYPEUi17DS3_PATH_ALARM_ID+152>: lwz  r0,88(r1) 
0x481a95c0 <notifyDs3PathAlarmClrEvent__F9PATH_TYPEUi17DS3_PATH_ALARM_ID+156>: stw  r9,12(r31) 
0x481a95c4 <notifyDs3PathAlarmClrEvent__F9PATH_TYPEUi17DS3_PATH_ALARM_ID+160>: stw  r0,20(r31) 
0x481a95c8 <notifyDs3PathAlarmClrEvent__F9PATH_TYPEUi17DS3_PATH_ALARM_ID+164>: stw  r5,24(r31) 
0x481a95cc <notifyDs3PathAlarmClrEvent__F9PATH_TYPEUi17DS3_PATH_ALARM_ID+168>: lbz  r0,89(r1) 
0x481a95d0 <notifyDs3PathAlarmClrEvent__F9PATH_TYPEUi17DS3_PATH_ALARM_ID+172>: mr  r3,r31 
0x481a95d4 <notifyDs3PathAlarmClrEvent__F9PATH_TYPEUi17DS3_PATH_ALARM_ID+176>: stb  r0,28(r31) 
0x481a95d8 <notifyDs3PathAlarmClrEvent__F9PATH_TYPEUi17DS3_PATH_ALARM_ID+180>: li  r4,32 
0x481a95dc <notifyDs3PathAlarmClrEvent__F9PATH_TYPEUi17DS3_PATH_ALARM_ID+184>: 

Answer 1

我以前的工作代码崩溃。核心转储指向正在调用的构造函数 。我已经试图获得bt，bt full和 反汇编。我需要一些帮助来确定在调用构造函数时可能导致段错误的原因是什么？代码在QNX上运行，并且 只有控制台gdb。局部变量全部为0，那么 这意味着什么？我需要一些帮助来确定在调用构造函数时可能导致段错误的原因是什么？

请不要断定调用构造函数时可能有问题（仅）。这可能仅仅是已经发生的其他（不良）副作用。 很难从当前堆栈跟踪中找出问题。某些时候，内存错误会非常间歇地（由于不同的输入/线程/执行顺序的变化）在非常间歇的（程序可能会运行多年，而不会出现任何问题的症状）。 当地人变量0可能表明它看起来不错，但我们不能从中得出任何结论。

我确实觉得可能会有一些内存损坏情况（您其他模块中的其他某个地方）正在领导此次崩溃。您将不得不使用GDB/Valgrind（某些动态工具）来调试代码，以找出根本问题。看起来您在QNX上遇到了这个问题，因此您可能需要运行Valgrind来识别代码中的问题。你可以参考我以前的帖子

https://stackoverflow.com/a/22658693/2724703