|
From: Jerry B. <je...@ge...> - 2013-10-15 22:52:00
|
I'm running valgrind on fedora 19. I checked libvex code which executes the hwcaps code, but can't find anything in particular. valgrind --tool=memcheck /bin/ls ==23682== Memcheck, a memory error detector ==23682== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==23682== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==23682== Command: /bin/ls ==23682== vex: priv/main_main.c:319 (LibVEX_Translate): Assertion `are_valid_hwcaps(VexArchAMD64, vta->archinfo_host.hwcaps)' failed. vex storage: T total 0 bytes allocated vex storage: P total 0 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). ==23682== at 0x38059B6F: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==23682== by 0x38059D31: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==23682== by 0x38059D5A: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==23682== by 0x38071252: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==23682== by 0x380F6618: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==23682== by 0x380F5640: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==23682== by 0x3807352F: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==23682== by 0x3809F096: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) ==23682== by 0x380AE0FC: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==23682== at 0x4001420: ??? (in /usr/lib64/ld-2.17.so) Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. ls -l /usr/bin/valgrind -rwxr-xr-x. 1 root root 19880 Apr 25 08:57 /usr/bin/valgrind Here's the CPU info cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD Opteron(tm) Processor 4332 HE stepping : 0 microcode : 0x600081f cpu MHz : 3000.098 cache size : 2048 KB fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu de tsc msr pae cx8 cmov pat clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm rep_good nopl pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 popcnt aes f16c hypervisor lahf_lm cmp_legacy extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch xop fma4 tce tbm perfctr_core perfctr_nb arat cpb hw_pstate bogomips : 6000.19 TLB size : 1536 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro uname -a Linux 3.10.11-200.fc19.x86_64 #1 SMP Mon Sep 9 13:03:01 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Thanks. Jerry |
|
From: Mark W. <mj...@re...> - 2013-10-16 13:55:48
|
On Tue, 2013-10-15 at 14:48 -0700, Jerry Blakley wrote:
> I'm running valgrind on fedora 19. I checked libvex code which
> executes the hwcaps code, but can't find anything in particular.
> vex: priv/main_main.c:319 (LibVEX_Translate): Assertion
> `are_valid_hwcaps(VexArchAMD64, vta->archinfo_host.hwcaps)' failed.
This will happen when valgrind/VEX doesn't understand the (combination
of) cpuid capabilities of your CPU.
Specifically show_hwcaps_amd64 () in VEX/priv/main_main.c should return
a valid string describing the configuration (not NULL).
The version in fedora valgrind 3.8.1 only handles fixed combinations of
flags, the version in valgrind SVN is more flexible.
> flags : fpu de tsc msr pae cx8 cmov pat clflush mmx fxsr sse sse2 ht
> syscall nx mmxext fxsr_opt lm rep_good nopl pni pclmulqdq ssse3 fma
> cx16 sse4_1 sse4_2 popcnt aes f16c hypervisor lahf_lm cmp_legacy
> extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch xop fma4 tce
> tbm perfctr_core perfctr_nb arat cpb hw_pstate
If I am reading that right, you don't have AVX, RDTSCP, BMI or AVX. You
do have SSE3 (pni), XC16 and LZCNT (abm)
Which should give you:
case VEX_HWCAPS_AMD64_SSE3 | VEX_HWCAPS_AMD64_CX16
| VEX_HWCAPS_AMD64_LZCNT:
return "amd64-sse3-cx16-lzcnt";
So I am probably missing some detail/flag.
Which fedora valgrind package version is this exactly?
You can tell by running "rpm -q valgrind".
Have you tried valgrind build from SVN?
Thanks,
Mark
|
|
From: Jerry B. <je...@ge...> - 2013-10-16 17:48:55
|
Hi Mark, Thanks for the note. Here's the version I've been using: valgrind-3.8.1-15.fc19.x86_64 I wasn't able to find a more recent fedora package. We run on servers at rackspace. There is an older generation of cpu's and valgrind works find on them. It is the newer (about a year-old) generation on which valgrind doesn't work. This was a big surprise, since I think they are stock processors. Might there be something in the VM/hypervisor layer which is not translating correctly? I did just go the svn route. The results look similar. valgrind]$ ll /usr/bin/valgrind -rwxr-xr-x. 1 root root 54427 Oct 16 17:44 /usr/bin/valgrind valgrind]$ valgrind ls -l ==21888== Memcheck, a memory error detector ==21888== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==21888== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info ==21888== Command: ls -l ==21888== vex: priv/main_main.c:338 (LibVEX_Translate): Assertion `are_valid_hwcaps(VexArchAMD64, vta->archinfo_host.hwcaps)' failed. vex storage: T total 0 bytes allocated vex storage: P total 0 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). ==21888== at 0x3804FBAC: report_and_quit (m_libcassert.c:260) ==21888== by 0x3804FDB1: vgPlain_core_panic_at (m_libcassert.c:350) ==21888== by 0x3804FDDA: vgPlain_core_panic (m_libcassert.c:360) ==21888== by 0x38067E32: failure_exit (m_translate.c:731) ==21888== by 0x380FA1F8: vex_assert_fail (main_util.c:219) ==21888== by 0x380F90AF: LibVEX_Translate (main_main.c:338) ==21888== by 0x3806A24E: vgPlain_translate (m_translate.c:1602) ==21888== by 0x3809B596: vgPlain_scheduler (scheduler.c:1004) ==21888== by 0x380AA6FC: run_a_thread_NORETURN (syswrap-linux.c:103) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==21888== at 0x315C601420: ??? (in /usr/lib64/ld-2.17.so) ==21888== by 0x1: ??? ==21888== by 0xFFF0005CA: ??? ==21888== by 0xFFF0005CD: ??? Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. Thanks. Jerry On Wed, Oct 16, 2013 at 6:55 AM, Mark Wielaard <mj...@re...> wrote: > On Tue, 2013-10-15 at 14:48 -0700, Jerry Blakley wrote: > > I'm running valgrind on fedora 19. I checked libvex code which > > executes the hwcaps code, but can't find anything in particular. > > > > vex: priv/main_main.c:319 (LibVEX_Translate): Assertion > > `are_valid_hwcaps(VexArchAMD64, vta->archinfo_host.hwcaps)' failed. > > This will happen when valgrind/VEX doesn't understand the (combination > of) cpuid capabilities of your CPU. > > Specifically show_hwcaps_amd64 () in VEX/priv/main_main.c should return > a valid string describing the configuration (not NULL). > > The version in fedora valgrind 3.8.1 only handles fixed combinations of > flags, the version in valgrind SVN is more flexible. > > > flags : fpu de tsc msr pae cx8 cmov pat clflush mmx fxsr sse sse2 ht > > syscall nx mmxext fxsr_opt lm rep_good nopl pni pclmulqdq ssse3 fma > > cx16 sse4_1 sse4_2 popcnt aes f16c hypervisor lahf_lm cmp_legacy > > extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch xop fma4 tce > > tbm perfctr_core perfctr_nb arat cpb hw_pstate > > If I am reading that right, you don't have AVX, RDTSCP, BMI or AVX. You > do have SSE3 (pni), XC16 and LZCNT (abm) > > Which should give you: > > case VEX_HWCAPS_AMD64_SSE3 | VEX_HWCAPS_AMD64_CX16 > | VEX_HWCAPS_AMD64_LZCNT: > return "amd64-sse3-cx16-lzcnt"; > > So I am probably missing some detail/flag. > > Which fedora valgrind package version is this exactly? > You can tell by running "rpm -q valgrind". > Have you tried valgrind build from SVN? > > Thanks, > > Mark > > |
|
From: Mark W. <mj...@re...> - 2013-10-16 18:34:38
|
On Wed, 2013-10-16 at 10:48 -0700, Jerry Blakley wrote: > Thanks for the note. Here's the version I've been using: > > valgrind-3.8.1-15.fc19.x86_64 > > I wasn't able to find a more recent fedora package. That is the latest stable version for f19. There are some newer versions for f20/rawhide, but I doubt they solve the issue. http://koji.fedoraproject.org/koji/packageinfo?packageID=98 > We run on servers at rackspace. There is an older generation of cpu's > and valgrind works find on them. It is the newer (about a year-old) > generation on which valgrind doesn't work. This was a big surprise, > since I think they are stock processors. Might there be something in > the VM/hypervisor layer which is not translating correctly? > > > I did just go the svn route. The results look similar. Then it at least isn't the fedora package/patches. Thanks for checking. So it must be some flag/cpuid combination valgrind isn't handling correctly. Would you mind installing cpuid (it is packaged for fedora) or building it from source: http://etallen.com/cpuid.html Then run: cpuid -1 and cpuid -1 -r Please file that output in a new bug at: https://bugs.kde.org/enter_bug.cgi?product=valgrind Thanks, Mark |
|
From: Jerry B. <je...@ge...> - 2013-10-16 20:26:06
|
Thanks. Created the bug: Bug 326113 - valgrind libvex hwcaps error on AMD64 Jerry On Wed, Oct 16, 2013 at 11:34 AM, Mark Wielaard <mj...@re...> wrote: > On Wed, 2013-10-16 at 10:48 -0700, Jerry Blakley wrote: > > > Thanks for the note. Here's the version I've been using: > > > > valgrind-3.8.1-15.fc19.x86_64 > > > > I wasn't able to find a more recent fedora package. > > That is the latest stable version for f19. > There are some newer versions for f20/rawhide, but I doubt they solve > the issue. http://koji.fedoraproject.org/koji/packageinfo?packageID=98 > > > We run on servers at rackspace. There is an older generation of cpu's > > and valgrind works find on them. It is the newer (about a year-old) > > generation on which valgrind doesn't work. This was a big surprise, > > since I think they are stock processors. Might there be something in > > the VM/hypervisor layer which is not translating correctly? > > > > > > I did just go the svn route. The results look similar. > > Then it at least isn't the fedora package/patches. Thanks for checking. > So it must be some flag/cpuid combination valgrind isn't handling > correctly. > > Would you mind installing cpuid (it is packaged for fedora) or building > it from source: http://etallen.com/cpuid.html > > Then run: > cpuid -1 > and > cpuid -1 -r > > Please file that output in a new bug at: > https://bugs.kde.org/enter_bug.cgi?product=valgrind > > Thanks, > > Mark > > > |
|
From: Mark W. <mj...@re...> - 2013-10-16 21:53:02
|
On Wed, 2013-10-16 at 13:02 -0700, Jerry Blakley wrote: > Thanks. Created the bug: Bug 326113 - valgrind libvex hwcaps error on > AMD64 Thanks. I added some comments and a proposed patch for valgrind SVN to that bug report. If you could try that out, that would be great. Mark |
|
From: Jerry B. <je...@ge...> - 2013-10-17 01:08:39
|
Mark, Looks good on this end. Thanks. Jerry valgrind]$ ll /usr/bin/valgrind -rwxr-xr-x 1 root root 54427 Oct 17 01:04 /usr/bin/valgrind valgrind]$ valgrind ls -l ==4957== Memcheck, a memory error detector ==4957== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==4957== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info ==4957== Command: ls -l ==4957== total 1712 -rw-r--r-- 1 jerry pantheon 41426 Oct 17 00:36 aclocal.m4 -rw-r--r-- 1 jerry pantheon 3097 Oct 17 00:35 AUTHORS -rwxr-xr-x 1 jerry pantheon 191 Oct 17 00:35 autogen.sh drwxr-xr-x 2 jerry pantheon 4096 Oct 17 00:37 autom4te.cache drwxr-xr-x 4 jerry pantheon 4096 Oct 17 00:41 auxprogs -rw-r--r-- 1 jerry pantheon 1285 Oct 17 00:35 bionic.supp drwxr-xr-x 5 jerry pantheon 4096 Oct 17 01:03 cachegrind drwxr-xr-x 5 jerry pantheon 4096 Oct 17 01:03 callgrind lrwxrwxrwx 1 jerry pantheon 32 Oct 17 00:37 compile -> /usr/share/automake-1.13/compile lrwxrwxrwx 1 jerry pantheon 37 Oct 17 00:37 config.guess -> /usr/share/automake-1.13/config.guess -rw-r--r-- 1 jerry pantheon 10675 Oct 17 00:37 config.h -rw-r--r-- 1 jerry pantheon 10013 Oct 17 00:36 config.h.in -rw-r--r-- 1 jerry pantheon 100412 Oct 17 00:38 config.log -rwxr-xr-x 1 jerry pantheon 50326 Oct 17 00:37 config.status lrwxrwxrwx 1 jerry pantheon 35 Oct 17 00:37 config.sub -> /usr/share/automake-1.13/config.sub -rwxr-xr-x 1 jerry pantheon 370866 Oct 17 00:37 configure -rw-r--r-- 1 jerry pantheon 86441 Oct 17 00:36 configure.ac -rw-r--r-- 1 jerry pantheon 17987 Oct 17 00:36 COPYING -rw-r--r-- 1 jerry pantheon 20415 Oct 17 00:35 COPYING.DOCS drwxr-xr-x 17 jerry pantheon 12288 Oct 17 01:03 coregrind -rw-r--r-- 1 jerry pantheon 2542 Oct 17 00:36 darwin10-drd.supp -rw-r--r-- 1 jerry pantheon 1727 Oct 17 00:35 darwin10.supp -rw-r--r-- 1 jerry pantheon 6268 Oct 17 00:36 darwin11.supp -rw-r--r-- 1 jerry pantheon 5911 Oct 17 00:35 darwin12.supp -rw-r--r-- 1 jerry pantheon 10266 Oct 17 00:36 darwin9-drd.supp -rw-r--r-- 1 jerry pantheon 7182 Oct 17 00:36 darwin9.supp -rw-r--r-- 1 jerry pantheon 29799 Oct 17 00:38 default.supp lrwxrwxrwx 1 jerry pantheon 32 Oct 17 00:37 depcomp -> /usr/share/automake-1.13/depcomp drwxr-xr-x 6 jerry pantheon 4096 Oct 17 00:37 docs drwxr-xr-x 6 jerry pantheon 4096 Oct 17 01:03 drd drwxr-xr-x 5 jerry pantheon 4096 Oct 17 01:03 exp-bbv drwxr-xr-x 5 jerry pantheon 4096 Oct 17 01:03 exp-dhat drwxr-xr-x 5 jerry pantheon 4096 Oct 17 01:03 exp-sgcheck -rw-r--r-- 1 jerry pantheon 372 Oct 17 00:36 exp-sgcheck.supp drwxr-xr-x 3 jerry pantheon 4096 Oct 17 00:37 gdbserver_tests -rw-r--r-- 1 jerry pantheon 1203 Oct 17 00:36 glibc-2.2-LinuxThreads-helgrind.supp -rw-r--r-- 1 jerry pantheon 9477 Oct 17 00:36 glibc-2.2.supp -rw-r--r-- 1 jerry pantheon 5759 Oct 17 00:36 glibc-2.34567-NPTL-helgrind.supp -rw-r--r-- 1 jerry pantheon 11294 Oct 17 00:36 glibc-2.3.supp -rw-r--r-- 1 jerry pantheon 4816 Oct 17 00:36 glibc-2.4.supp -rw-r--r-- 1 jerry pantheon 3941 Oct 17 00:35 glibc-2.5.supp -rw-r--r-- 1 jerry pantheon 4795 Oct 17 00:36 glibc-2.6.supp -rw-r--r-- 1 jerry pantheon 695 Oct 17 00:35 glibc-2.7.supp -rw-r--r-- 1 jerry pantheon 6769 Oct 17 00:36 glibc-2.X-drd.supp -rw-r--r-- 1 jerry pantheon 4749 Oct 17 00:37 glibc-2.X.supp -rw-r--r-- 1 jerry pantheon 5277 Oct 17 00:35 glibc-2.X.supp.in drwxr-xr-x 5 jerry pantheon 4096 Oct 17 01:03 helgrind drwxr-xr-x 3 jerry pantheon 4096 Oct 17 00:37 include lrwxrwxrwx 1 jerry pantheon 35 Oct 17 00:37 install-sh -> /usr/share/automake-1.13/install-sh drwxr-xr-x 5 jerry pantheon 4096 Oct 17 01:03 lackey -rw-r--r-- 1 jerry pantheon 41909 Oct 17 00:37 Makefile -rw-r--r-- 1 jerry pantheon 8372 Oct 17 00:35 Makefile.all.am -rw-r--r-- 1 jerry pantheon 3362 Oct 17 00:35 Makefile.am -rw-r--r-- 1 jerry pantheon 42614 Oct 17 00:37 Makefile.in -rw-r--r-- 1 jerry pantheon 5616 Oct 17 00:36 Makefile.tool.am -rw-r--r-- 1 jerry pantheon 1372 Oct 17 00:35 Makefile.tool-tests.am -rw-r--r-- 1 jerry pantheon 4585 Oct 17 00:35 Makefile.vex.am -rw-r--r-- 1 jerry pantheon 296066 Oct 17 00:37 Makefile.vex.in drwxr-xr-x 5 jerry pantheon 4096 Oct 17 01:03 massif drwxr-xr-x 5 jerry pantheon 4096 Oct 17 01:03 memcheck lrwxrwxrwx 1 jerry pantheon 32 Oct 17 00:37 missing -> /usr/share/automake-1.13/missing drwxr-xr-x 3 jerry pantheon 4096 Oct 17 00:37 mpi -rw-r--r-- 1 jerry pantheon 105926 Oct 17 00:35 NEWS -rw-r--r-- 1 jerry pantheon 86605 Oct 17 00:36 NEWS.old drwxr-xr-x 4 jerry pantheon 4096 Oct 17 00:36 nightly drwxr-xr-x 5 jerry pantheon 4096 Oct 17 01:03 none drwxr-xr-x 3 jerry pantheon 4096 Oct 17 00:37 perf -rw-r--r-- 1 jerry pantheon 3237 Oct 17 00:35 README -rw-r--r-- 1 jerry pantheon 5389 Oct 17 00:35 README.android -rw-r--r-- 1 jerry pantheon 1884 Oct 17 00:35 README.android_emulator -rw-r--r-- 1 jerry pantheon 11384 Oct 17 00:35 README_DEVELOPERS -rw-r--r-- 1 jerry pantheon 2157 Oct 17 00:36 README.mips -rw-r--r-- 1 jerry pantheon 6936 Oct 17 00:35 README_MISSING_SYSCALL_OR_IOCTL -rw-r--r-- 1 jerry pantheon 4463 Oct 17 00:35 README_PACKAGERS -rw-r--r-- 1 jerry pantheon 1994 Oct 17 00:36 README.s390 -rw-r--r-- 1 jerry pantheon 23 Oct 17 00:37 stamp-h1 drwxr-xr-x 3 jerry pantheon 4096 Oct 17 00:37 tests -rw-r--r-- 1 jerry pantheon 369 Oct 17 00:37 valgrind.pc -rw-r--r-- 1 jerry pantheon 447 Oct 17 00:35 valgrind.pc.in -rw-r--r-- 1 jerry pantheon 1219 Oct 17 00:37 valgrind.spec -rw-r--r-- 1 jerry pantheon 1222 Oct 17 00:36 valgrind.spec.in drwxr-xr-x 15 jerry pantheon 4096 Oct 17 00:40 VEX -rwxr-xr-x 1 jerry pantheon 691 Oct 17 00:36 vg-in-place -rw-r--r-- 1 jerry pantheon 2946 Oct 17 00:36 xfree-3.supp -rw-r--r-- 1 jerry pantheon 9018 Oct 17 00:36 xfree-4.supp ==4957== ==4957== HEAP SUMMARY: ==4957== in use at exit: 22,689 bytes in 97 blocks ==4957== total heap usage: 418 allocs, 321 frees, 97,864 bytes allocated ==4957== ==4957== LEAK SUMMARY: ==4957== definitely lost: 0 bytes in 0 blocks ==4957== indirectly lost: 0 bytes in 0 blocks ==4957== possibly lost: 0 bytes in 0 blocks ==4957== still reachable: 22,689 bytes in 97 blocks ==4957== suppressed: 0 bytes in 0 blocks ==4957== Rerun with --leak-check=full to see details of leaked memory ==4957== ==4957== For counts of detected and suppressed errors, rerun with: -v ==4957== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2) On Wed, Oct 16, 2013 at 2:52 PM, Mark Wielaard <mj...@re...> wrote: > On Wed, 2013-10-16 at 13:02 -0700, Jerry Blakley wrote: > > Thanks. Created the bug: Bug 326113 - valgrind libvex hwcaps error on > > AMD64 > > Thanks. I added some comments and a proposed patch for valgrind SVN to > that bug report. If you could try that out, that would be great. > > Mark > > > |