cancel
Showing results for 
Search instead for 
Did you mean: 

Core file debugging wdb and gdb

 
SOLVED
Go to solution
Highlighted
Frequent Advisor

Core file debugging wdb and gdb

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.
5 REPLIES 5
Highlighted
Valued Contributor

Re: Core file debugging wdb and gdb

try "bt full"

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

Thanks
Sri
abandon all hope, ye who enter here..
Highlighted
Acclaimed Contributor

Re: Core file debugging wdb and gdb

>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
Highlighted
Frequent Advisor

Re: Core file debugging wdb and gdb

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
Highlighted
Acclaimed Contributor
Solution

Re: Core file debugging wdb and gdb

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


Highlighted
Frequent Advisor

Re: Core file debugging wdb and gdb

Great!....

Thanks to all.