Bug 265771

Is it possible to freshly install your old LFS system with the packages
from ftp://ftp.lfs-matrix.net/pub/lfs/lfs-packages/ ?
Which version should I choose?

The source was on http://www.linuxfromscratch.org (LFS-BOOK-3.2).
Now that source is in the museum and the links in http://archive.linuxfromscratch.org/lfs-museum/3.2/LFS-BOOK-3.2-HTML/chapter03/packages.html
are not online anymore.

In the last years some of the packages were also (conservatively) updated.

At the moment the main package versions concerning valgrind (as far as I know) are:
linux-2.6.17.13
glibc-2.3.5
binutils-2.16.1
gcc-3.4.4

This is almost what can be found on ftp://ftp.lfs-matrix.net/pub/lfs/lfs-packages/6.1/

Hi.

I encountered the same problem on a RHEL 4 machine. Callgrind works ok with 3.6.0 but I get the error with 3.6.1 and latest trunk (r11577).

With the small testcase from bug 246152, I get the following trace:
==24870== Callgrind, a call-graph generating cache profiler
==24870== Copyright (C) 2002-2010, and GNU GPL'd, by Josef Weidendorfer et al.
==24870== Using Valgrind-3.7.0.SVN and LibVEX; rerun with -h for copyright info
==24870== Command: ./a.out
==24870==
==24870== For interactive control, run 'callgrind_control -h'.
memcpy
BB# 28345

Callgrind: jumps.c:164 (new_jcc): Assertion '(0 <= jmp) && (jmp <= from->bb->cjmp_count)' failed.
==24870==    at 0x3801982D: report_and_quit (m_libcassert.c:193)
==24870==    by 0x38019908: vgPlain_assert_fail (m_libcassert.c:267)
==24870==    by 0x3800D863: vgCallgrind_get_jcc (jumps.c:164)
==24870==    by 0x3800297F: vgCallgrind_push_call_stack (callstack.c:217)
==24870==    by 0x38001C29: vgCallgrind_setup_bbcc (bbcc.c:844)
==24870==    by 0x62C4C463: ???

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable
==24870==    at 0x36B0D0: memcpy (in /lib/tls/libc-2.3.4.so)
==24870==    by 0x5605A8: __pthread_initialize_minimal (in /lib/tls/libpthread-2.3.4.so)
==24870==    by 0x5602D7: ??? (in /lib/tls/libpthread-2.3.4.so)
==24870==    by 0x55FEA7: ??? (in /lib/tls/libpthread-2.3.4.so)
==24870==    by 0x2F2921: _dl_init (in /lib/ld-2.3.4.so)
==24870==    by 0x2E67FE: ??? (in /lib/ld-2.3.4.so)

Some information on the machine:

[emmanuel@fengr1]$cat /etc/redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 6)

[emmanuel@fengr1]$uname -a
Linux fengr1 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:58:04 EST 2007 i686 i686 i386 GNU/Linux

[emmanuel@fengr1]$rpm -qa | grep glibc
glibc-devel-2.3.4-2.39
glibc-headers-2.3.4-2.39
glibc-2.3.4-2.39
glibc-kernheaders-2.4-9.1.100.EL
glibc-common-2.3.4-2.39

[emmanuel@fengr1]/tmp/test_valg$gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-9)

Does this appear with every piece of code, ie. it is also completely
reproducable for you?

It should be easier to install RHEL4 in a VM for me to be able to reproduce
than an old LFS...

I found the problem running callgrind on a personal code (not sharable unfortunately) and I always get that behavior every time I try to run callgrind on it.

And in fact, I've just realized that even running callgrind on /bin/ls produces the same problem.

And an empty program like the following:
[emmanuel@fengr1]/tmp/test_valg$cat foo.c
int main(int argc, char* argv[])
{
  return 0;
}

always produces the following result:

[emmanuel@fengr1]$valgrind --tool=callgrind ./a.out
==1838== Callgrind, a call-graph generating cache profiler
==1838== Copyright (C) 2002-2010, and GNU GPL'd, by Josef Weidendorfer et al.
==1838== Using Valgrind-3.7.0.SVN and LibVEX; rerun with -h for copyright info
==1838== Command: ./a.out
==1838==
==1838== For interactive control, run 'callgrind_control -h'.
(below main)
BB# 19580

Callgrind: jumps.c:164 (new_jcc): Assertion '(0 <= jmp) && (jmp <= from->bb->cjmp_count)' failed.
==1838==    at 0x3801982D: report_and_quit (m_libcassert.c:193)
==1838==    by 0x38019908: vgPlain_assert_fail (m_libcassert.c:267)
==1838==    by 0x3800D863: vgCallgrind_get_jcc (jumps.c:164)
==1838==    by 0x3800297F: vgCallgrind_push_call_stack (callstack.c:217)
==1838==    by 0x38001C29: vgCallgrind_setup_bbcc (bbcc.c:844)
==1838==    by 0x62CA43D3: ???

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable
==1838==    at 0x314D10: (below main) (in /lib/tls/libc-2.3.4.so)

With a VM image for CentOS 4.6, I was able to reproduce the bug.
Can you check if the following patch works for you?

diff --git a/callgrind/bbcc.c b/callgrind/bbcc.c
index bab4858..4b01b97 100644
--- a/callgrind/bbcc.c
+++ b/callgrind/bbcc.c
@@ -693,6 +693,7 @@ void CLG_(setup_bbcc)(BB* bb)
                /* change source for delayed push */
                CLG_(current_state).bbcc = top_ce->jcc->from;
                sp = top_ce->sp;
+               passed = top_ce->jcc->jmp;
                CLG_(pop_call_stack)();
            }
            else {

The patch seems to correct the problem. I don't get the error anymore either with the small testcases or with my original test program. Thanks !

The fix works also for our old LFS based system - thanks.

Thanks. Fixed in r11579.
Should be backported for a 3.6.2 version (no idea when this happens,
as 3.6.1 is quite fresh).