Unix Programming - dbx debugging

Author

dbx debugging

nprashanth@gmail.com

2006-04-27, 7:55 am

Hi,

When I read a core file in dbx, and print the stack trace I get the
addresses and not the values of the parameters. Why is that so? And how
can I see the values in the addresses? Here is the stack trace:

=>[1] strlen(0x0, 0x69636558, 0x330678, 0x7efefeff, 0x81010100, 0x8),
at 0xfb2344e4
[2] CORBA::string_dup(0x69636558, 0x0, 0x330668, 0xfbb4b554,
0xfbacca80, 0x960), at 0xfb72f0e4
[3]
TAO_Bindings_Iterator<ACE_Hash_Map_Iterator_Ex<TAO_ExtId,TAO_IntId,ACE_Hash<TAO_ExtId>,ACE_Equal_To<TAO_ExtId>,ACE_Null_Mutex>,ACE_Hash_Map_Entry<TAO_ExtId,TAO_IntId>
>::populate_binding(0x19177d8, 0x1938338, 0x0, 0x2c1, 0xffbfe944, 0x23494), at 0xfbad1144

[4]
TAO_Bindings_Iterator<ACE_Hash_Map_Iterator_Ex<TAO_ExtId,TAO_IntId,ACE_Hash<TAO_ExtId>,ACE_Equal_To<TAO_ExtId>,ACE_Null_Mutex>,ACE_Hash_Map_Entry<TAO_ExtId,TAO_IntId>
>::next_n(0x18da828, 0x64, 0xffbfe8d4, 0xfc, 0xfbb49520, 0x0), at 0xfbad1f40

[5] POA_CosNaming::BindingIterator::next_n_s
kel(0xffbfecc8,
0x18da878, 0xffbfea18, 0xfbaf3f88, 0xfbb49474, 0x0), at 0xfbaf4070
[6] TAO_ServantBase::synchronous_upcall_disp
atch(0x18da840,
0xffbfecc8, 0xffbfea18, 0x18da878, 0xfbb49400, 0xfb97eb60), at
0xfb97ec54
[7] TAO_Object_Adapter::dispatch_servant(0x0
, 0xffbfed34, 0xffbfecc8,
0xffbfeaf4, 0x0, 0xc4), at 0xfb94e71c
[8] TAO_Object_Adapter::dispatch(0x4eae8, 0xffbfed34, 0xffbfecc8,
0xffbfebac, 0x3e118, 0x3ddb0), at 0xfb94f604
[9] TAO_Adapter_Registry::dispatch(0x3df20, 0xffbfed34, 0xffbfecc8,
0xffbfec14, 0x6c, 0x1), at 0xfb79fdac
[10] TAO_Request_Dispatcher::dispatch(0x26c58
, 0x3ddb0, 0xffbfecc8,
0xffbfecb8, 0x3ddb0, 0xfb869984), at 0xfb7b1798
[11] TAO_GIOP_Message_Base::process_request(0
x1905348, 0x19185e8,
0xffbfee28, 0xffbff068, 0x0, 0x1), at 0xfb6f4ccc
[12] TAO_GIOP_Message_Base::process_request_m
essage(0x1905348,
0x19185e8, 0x18ca188, 0xffbff068, 0x33cdf0, 0x0), at 0xfb6f4694
[13] TAO_Transport::process_parsed_messages(0
x19185e8, 0x18ca188,
0xffbff71c, 0x0, 0x0, 0x0), at 0xfb6e0f6c
[14] TAO_Transport::process_queue_head(0x1918
5e8, 0xffbff71c, 0x324,
0xfb869694, 0xfb860188, 0x0), at 0xfb6e1294
[15] TAO_Transport::handle_input(0x19185e8, 0xffbff71c, 0x0, 0x1,
0x187a2c, 0x2d94), at 0xfb6dfe50
[16] TAO_Connection_Handler::handle_input_int
ernal(0x0, 0xffffffff,
0x1913808, 0x3ddb0, 0xfb6e5bb0, 0xfb6cc214), at 0xfb6e584c
[17] TAO_Connection_Handler::handle_input_eh(
0x19138a8, 0xffffffff,
0x1913808, 0x0, 0x16bb58, 0x19185e8), at 0xfb6e56f0
[18] ACE_Select_Reactor_Notify::dispatch_noti
fy(0x4d9e0, 0xffbff848,
0xacb58, 0xfb5bbb50, 0xfb5b0e7c, 0xffffffff), at 0xfb5043c8
[19] ACE_TP_Reactor::handle_notify_events(0x0
, 0x20, 0xffbff920,
0x20, 0x20, 0x0), at 0xfb505f6c
[20] ACE_TP_Reactor::dispatch_i(0x0, 0x0, 0xffbff920, 0x0, 0x0, 0x0),
at 0xfb505cc4
[21] ACE_TP_Reactor::handle_events(0x4d240, 0x0, 0x0, 0xfb502940,
0xfb8510e8, 0xffbff930), at 0xfb505b40
[22] TAO_ORB_Core::run(0x3ddb0, 0x0, 0xfb5030cc, 0xfb5ba104, 0x23cf8,
0x4), at 0xfb778cb4
[23] TAO_Naming_Service::run(0xffbffadc, 0x5, 0xffbffb94, 0xfbbb3a7c,
0xfffef9a0, 0xfffef748), at 0x11d5c
[24] main(0x5, 0xffbffb94, 0xffbffbac, 0x22c00, 0x0, 0x0), at 0x11934

Thanks.

Paul Floyd

2006-04-27, 7:55 am

On 19 Apr 2006 11:01:24 -0700, nprashanth@gmail.com
<nprashanth@gmail.com> wrote:
> Hi,
>
> When I read a core file in dbx, and print the stack trace I get the
> addresses and not the values of the parameters. Why is that so? And how
> can I see the values in the addresses? Here is the stack trace:

You need to compile debug info, with -g.

A bientot
Paul
--
Paul Floyd http://paulf.free.fr (for what it's worth)
Surgery: ennobled Gerald.

chris

2006-04-27, 7:56 am

nprashanth@gmail.com wrote:
> Hi,
>
> When I read a core file in dbx, and print the stack trace I get the
> addresses and not the values of the parameters. Why is that so? And how
> can I see the values in the addresses?

Use the "examine" command in dbx (see "help examine" in dbx).

> Here is the stack trace:
>
> =>[1] strlen(0x0, 0x69636558, 0x330678, 0x7efefeff, 0x81010100, 0x8),
> at 0xfb2344e4

Here, it looks like a null-pointer being passed to strlen().

Fletcher Glenn

2006-04-27, 7:56 am

"chris" <cklutz@gmail.com> wrote in message
news:1145521501.786274.276170@i40g2000cwc.googlegroups.com...
>
> nprashanth@gmail.com wrote:
>
> Use the "examine" command in dbx (see "help examine" in dbx).
>
>
> Here, it looks like a null-pointer being passed to strlen().
>

It depends on the dbx you're using. On the later flavors of Sun, the first
argument is the "this" pointer from C++ which I assume you are using because
of the references to TAO. The second argument is the string pointer. In
this case it appears that you are actually passing the string data because
the hex value translates to "iceX" and not a valid pointer.

--

Fletcher Glenn

Paul Pluzhnikov

2006-04-27, 7:56 am

"Fletcher Glenn" <fandxxxmgiiBLOCKED@pacbell.net> writes:

> "chris" <cklutz@gmail.com> wrote in message
> news:1145521501.786274.276170@i40g2000cwc.googlegroups.com...

And that caused a crash ...
[vbcol=seagreen]
> It depends on the dbx you're using. On the later flavors of Sun, the first
> argument is the "this" pointer from C++

Only if the function is a non-static member function (which strlen() isn't):

$ cat junk.cc
#include <string.h>
struct Foo { size_t fn(const char *p); };
size_t Foo::fn(const char *p) { return strlen(p); }
int main() { Foo f; return f.fn(0); }

$ CC junk.cc && dbx ./a.out
(dbx) run
Running: a.out
(process id 20269)
signal SEGV (no mapping at the fault address) in strlen at 0xff236f2c
0xff236f2c: strlen+0x0080: ld [%o1], %o2
(dbx) where
=>[1] strlen(0x0, 0x0, 0x1, 0x7efefeff, 0x81010100, 0xff38a810), at 0xff236f2c
^^^ no "this" pointer here ...
[2] Foo::fn(0xffbef573, 0x0, 0xff2b7f28, 0xff3b2c28, 0xfffefe58, 0xfffefe58), at 0x1086c
[3] main(0x1, 0xffbef5dc, 0xffbef5e4, 0x20800, 0x0, 0x0), at 0x108b0

> which I assume you are using because
> of the references to TAO. The second argument is the string pointer.

I believe Chris's diagnosis is correct, while yours is wrong.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

chris

2006-04-27, 7:56 am

Paul Pluzhnikov wrote:
> "Fletcher Glenn" <fandxxxmgiiBLOCKED@pacbell.net> writes:
>
>
>
> And that caused a crash ...
>
>
> Only if the function is a non-static member function (which strlen() isn't):
>

Yes, exactly.

[snip]

FWIW I just recalled that I have seen something similar some time back.
Here is a message by Mike Shapiro, http://tinyurl.com/elufz, i.e.
http://groups.google.com/group/comp...8fe2adf3%2Ff172
09e46dde53b5%3Flnk%3Dst%26q%3Dmike+shapi
ro+pstack+SPARC+group%3Acomp.unix. solaris%26rnum%3D1%26hl%3Den%26#doc_f172
09e46dde53b5,
that explains how Solaris' pstack command output is to be read (which
is also applies to dbx non-debug output AFAIK). It is at least
applicable for SPARC Solaris systems, although the original author
didn't tell, it could be what he is using.