On Saturday 21 February 2009, Nicholas Nethercote wrote: > On Thu, Feb 19, 2009 at 7:33 AM, Josef Weidendorfer > <[email protected]> wrote: > >> > >> . . > 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's amd64/Linux.
Ok. The inner loop of strcmp() on amd64 jumps back to the start of the function; following machine code is from glibc 2.7, therefore the relative address does not match your output, but it is obviously the same "issue": 000000000007aae0 <strcmp>: 7aae0: 8a 07 mov (%rdi),%al 7aae2: 3a 06 cmp (%rsi),%al 7aae4: 75 0d jne 7aaf3 <strcmp+0x13> 7aae6: 48 ff c7 inc %rdi 7aae9: 48 ff c6 inc %rsi 7aaec: 84 c0 test %al,%al 7aaee: 75 f0 jne 7aae0 <strcmp> 7aaf0: 31 c0 xor %eax,%eax 7aaf2: c3 retq 7aaf3: b8 01 00 00 00 mov $0x1,%eax 7aaf8: b9 ff ff ff ff mov $0xffffffff,%ecx 7aafd: 0f 42 c1 cmovb %ecx,%eax 7ab00: c3 retq Callgrind assumes tail recursion optimized by the compiler, and shows the jump back to the start as a recursive call. In this case, the heuristic is a bit misguided. But it really could be that strcmp is coded using tail recursion. If you know a better heuristic, please tell me. The best probably would be something similar to the suppression system used by memcheck, to specify the interpretation of the code for a given function. The strange values after "strcmp( ..." just show random content from the stack, as strcmp() does not use the stack, but passes all arguments in registers. So apart from the misguided heuristic, the output is expected. Josef > > Nick > ------------------------------------------------------------------------------ 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
