|
From: Josef W. <Jos...@gm...> - 2009-02-18 20:34:09
|
On Wednesday 18 February 2009, Nicholas Nethercote wrote:
> On Thu, Feb 19, 2009 at 6:36 AM, Josef Weidendorfer
> <Jos...@gm...> wrote:
> >
> > . . > memcpy(0x8062c0d, 0xbefda9d4, ...) [libc-2.9.so / 0x75c40]
> > . . > memcpy(0x8062c13, 0xbefda9db, ...) [libc-2.9.so / 0x75c40]
> > . . > fgets_unlocked(0xbefda9d4, 0x190, ...) [libc-2.9.so / 0x67380]
> > . . > 0x0001653f(0x8062518, 0xbefda9d4, ...) [libc-2.9.so / 0x1653f]
> > . . > _IO_getline(0x8062518, 0xbefda9d4, ...) [libc-2.9.so / 0x5deb0]
> > . . .> 0x0001653f(0x8062518, 0xbefda9d4, ...) [libc-2.9.so / 0x1653f]
> > . . .> _IO_getline_info(0x8062518, 0xbefda9d4, ...) [libc-2.9.so / 0x5df00]
> > . . . > 0x0001653f(0xbefda9d4, 0x4024793, ...) [libc-2.9.so / 0x1653f]
> > . . . > memchr(0x40247a6, 0xa, ...) [libc-2.9.so / 0x752f0]
> > . . . > memcpy(0xbefda9d4, 0x40247a6, ...) [libc-2.9.so / 0x75c40]
> > . . > index(0xbefda9d4, 0xa, ...) [libc-2.9.so / 0x73460]
> > ...
> >
> > If somebody can derive enough information from debug info to allow for output similar
> > to "strace" or "ltrace", this for sure is welcome, and probably would rectify its own
> > tool "vtrace".
>
> I just tried this on the simple program 'date' and got lots of lines like this:
>
> . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> . . .> strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> . . . .> strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> . . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> . . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> . . . . > strcmp(0x0, 0xfefffce6, ...) [libc-2.8.90.so / 0x82210]
> [and 1000s more lines like it]
>
> What's happening there?
Indead, that looks quite strange. What architecture is this?
("valgrind --tool=callgrind --ct-verbose=1 date" looks reasonable here on x86).
It could be a case of a loop going back to the function entry, and callgrind
assuming tail recursion, but that doesn't make sense here.
> And what does the "..." mean?
The hex numbers after "strcmp(" are 32bit values which happen to appear on
the stack, and on x86 this matched the first two parameters last time
I checked. The "..." just is a hint that callgrind actually is clueless about the
number of parameters.
> (I looked in
> the manual but didn't see anything about this.)
Yes, as you see above, there is a reason for this. It just is meant as internal
unstable debugging aid, which happens to work sometimes on some architecture.
Josef
>
> N
>
|