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_E
qual_To<TAO_ExtId>,ACE_Null_Mutex>,ACE_Hash_Map_Entry<TAO_ExtId,TAO_IntId>
>::populate_binding(0x19177d8, 0x1938338, 0x0, 0x2c1, 0xffbfe944, 0x23494), at 0xfba
d1144

[4]
TAO_Bindings_Iterator<ACE_Hash_Map_Iterator_Ex<TAO_ExtId,TAO_IntId,ACE_Hash<TAO_ExtId>,ACE_E
qual_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.

[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

"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

[ Post a follow-up to this message ]

"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 firs
t
> 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 0xff
236f2c
^^^ no "this" pointer here ...
[2] Foo::fn(0xffbef573, 0x0, 0xff2b7f28, 0xff3b2c28, 0xfffefe58, 0xfffef
e58), 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.

[ Post a follow-up to this message ]

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...r />
f3%2Ff172
 09e46dde53b5%3Flnk%3Dst%26q%3Dmike+shapi
ro+pstack+SPARC+group%3Acomp.unix.so
 laris%26rnum%3D1%26hl%3Den%26#doc_f17209
e46dde53b5,
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.

[ Post a follow-up to this message ]