On Wednesday 18 February 2009, Nicholas Nethercote wrote:
> On Thu, Feb 19, 2009 at 6:36 AM, Josef Weidendorfer
> <[email protected]> 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
>
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
