Debug Core dump in QNX - How to get more info?

Question

My previously working code crashes now. The core dump points to the constructor being called. I have tried to get bt, bt full and disassembly. I need some help to conclude what could cause segmentation fault while calling constructor? Code is run on QNX and there is console gdb only. The local variables are all 0, what could that mean ?

Here's the 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 of Disassembly:

    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>:

score 0 · Answer 1 · edited May 23 '17 at 11:49

My previously working code crashes now. The core dump points to the constructor being called. I have tried to get bt, bt full and disassembly. I need some help to conclude what could cause segmentation fault while calling constructor? Code is run on QNX and there is console gdb only. The local variables are all 0, what could that mean ?. I need some help to conclude what could cause segmentation fault while calling constructor?

Please do not conclude that there could be problem(only) while calling constructor. This can be just the side effect of something else(bad) which has already occurred. It would be difficult to figure out the problem from the current stack trace. Sometime memory bugs would be in very intermittent(due to different input/threading/change in sequence of execution),and program may run for years without showing any symptoms of any problem. The locals variables 0 may indicate that it looks ok but we can not conclude anything from it.

I do feel that there could be some memory corruption scenario (somewhere else in your other module)is leading this crash. You would have to debug your code using GDB/Valgrind(some dynamic tool) to find out the root problem. It looks like you are experiencing this problem on QNX, so you may want to run the Valgrind to identify the problem in your code. You can refer to my previous post

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

Yes, I suspected that the actual problematic location could be somewhere else. I wasnt sure if we can run Valgrind on QNX. We cannot run our program in exec mode for GDB or Valgrind. Will it help in that case ? — Fatema Merchant, Apr 08 '14 at 13:12
@FatemaMerchant: I quickly checked about Valgrind on QNX platform and it look like it does not run on QNX(I am not very much familiar wirh QNX). Well in this case debugging the code using GDB seems to be option. Debugging would be certainly useful than static code analysis for memory related problem. I just shared my view so that you should start looking/analyzing it from this perspective. good luck. — Mantosh Kumar, Apr 08 '14 at 14:14

Debug Core dump in QNX - How to get more info?

1 Answers1