Core file debugging wdb and gdb

[Benedetto Mangiapane]

Hi,
Can You explain to me how do I see the same output of wdb "call stack" command, with gdb core file debugging?

example:

gdb /release/ntm/bin/NtmCmTom core
...
(gdb) bt
#0 0xc020c770 in kill () from /lib/libc.2
#1 0xc01a6dac in raise () from /lib/libc.2
#2 0xc01e8100 in abort_C () from /lib/libc.2
#3 0xc01e815c in abort () from /lib/libc.2
#4 0xca0150bc in sqlprc_ () from /opt/tcsi/osp/5.4/hpux1111/lib/libskel.sl
#5 0xc01a6dac in raise () from /lib/libc.2
Cannot access memory at address 0xca014548

wdb /release/ntm/bin/NtmCmTom core
...
Open window WDB
...
Call Stack
...
#0 0xc020c770 in kill+0x10 () from /lib/libc.2
#1 0xc01a6dac in raise+0x24 () from /lib/libc.2
#2 0xc01e8100 in abort_C+0x160 () from /lib/libc.2
#3 0xc01e815c in abort+0x1c () from /lib/libc.2
#4 0xca0150bc in skSigMgmt::_OspSignalWrapper+0xb48 () from /opt/tcsi/osp/5.4/hpux1111/lib/libskel.sl
#5
#6 0xc020c770 in kill+0x10 () from /lib/libc.2
#7 0xc01a6dac in raise+0x24 () from /lib/libc.2
#8 0xc01e8058 in abort_C+0xb8 () from /lib/libc.2
#9 0xc01e815c in abort+0x1c () from /lib/libc.2
#10 0xc03236ac in terminate+0x38 () from /lib/libCsup.2
#11 0xc0323b64 in ThrowException+0x70 () from /lib/libCsup.2
#12 0xc03240c4 in __throw__FPvT1+0x14c () from /lib/libCsup.2
#13 0xc0326aec in operator new []+0x124 () from /lib/libCsup.2
#14 0xca08bcc4 in aecCreateXDRExpandableBuf+0x94 () from /opt/tcsi/osp/5.4/hpux1111/lib/libAec.sl
#15 0xca0878f8 in aecMsg::aecMsg+0xf0 () from /opt/tcsi/osp/5.4/hpux1111/lib/libAec.sl
#16 0xca073984 in aecSyncCliConnEndpt::SendSync+0x2e8 () from /opt/tcsi/osp/5.4/hpux1111/lib/libAec.sl
#17 0xca0c11b8 in nsSyncInvoker::LookupManagers+0x148 () from /opt/tcsi/osp/5.4/hpux1111/lib/libAec.sl
#18 0xca1337f0 in evMoSieveGlobalProviderSession::_GetTOMIdList+0xd70 () from /opt/tcsi/osp/5.4/hpux1111/lib/libEvents.sl
#19 0xca131668 in evMoSieveGlobalProviderSession::HandleRegisterRequest+0x148 () from /opt/tcsi/osp/5.4/hpux1111/lib/libEvents.sl
#20 0xca124238 in evMoSieveServiceProvider::HandleRequest+0x908 () from /opt/tcsi/osp/5.4/hpux1111/lib/libEvents.sl
#21 0xca08867c in aecMsg::_HandleRequestWrapper+0x19c () from /opt/tcsi/osp/5.4/hpux1111/lib/libAec.sl
#22 0xc9e9f618 in thrThreadPool::FunctionWrapper+0xec () from /opt/tcsi/osp/5.4/hpux1111/lib/libOspThreads.sl
#23 0xc9ea297c in thrThreadServerPOSIX::_Run+0x2b8 () from /opt/tcsi/osp/5.4/hpux1111/lib/libOspThreads.sl
#24 0xc004b00c in __pthread_body+0x44 () from /lib/libpthread.1
#25 0xc005529c in __pthread_start+0x14 () from /lib/libpthread.1


Why the gdb backtrace command, not explain 25 frames?

Thanks and excuse me for my english.

[Srimalik]

try "bt full"

Which gdb is it, the one which comes with wdb or you have built it yourself?

Thanks
Sri

[Dennis Handly]

>Can you explain to me how do I see the same output of wdb "call stack" command, with gdb core file debugging?

Are you on the same system where the abort occurred? What gdb version are you running?
Otherwise they should be the same.

>gdb /release/ntm/bin/NtmCmTom core
(gdb) bt
#3 0xc01e815c in abort libc.2
#4 0xca0150bc in sqlprc_ libskel.sl
#5 0xc01a6dac in raise libc.2
Cannot access memory at address 0xca014548

This indicates that something is wrong, like a mismatch in shlibs. #5 is a dup of #1 and indicates gdb is lost.

>wdb /release/ntm/bin/NtmCmTom core

This should give the same output if wdb is invoking the same gdb version.

#12 0xc03240c4 in __throw__FPvT1 libCsup.2
#13 0xc0326aec in operator new[] libCsup.2

This says you are out of heap space.

>Why the gdb backtrace command, missing ... frames?

Not sure. As Sri asks, what gdb is running?
The latest wdb/gdb can be downloaded from:
http://www.hp.com/go/wdb

[Benedetto Mangiapane]

The version of wdb is:
HP WDB-GUI - HP Debugger Graphical User Interface - Version 3.1.1
Rev: 20020828.160156

The version of gdb is:
GNU gdb 5.3

The system is the same.

The question is why the gdb bt command, stop the output at "Cannot access memory at address 0xca014548" (after #5 frame), while the wdb makes you see from 25th frame?

How can I use gdb to see the same thing?

Thanks

[Dennis Handly · Accepted solution]

>The version of gdb is: GNU gdb 5.3
>How can I use gdb to see the same thing?

This looks like a foreign devil version of gdb.
You need to invoke HP's /opt/langtools/bin/gdb.

[Benedetto Mangiapane]

Great!....

Thanks to all.