Version: 3.4.1 (using KDE 4.2.4) OS: Linux Installed from: Mandriva RPMs I got this when running a program under memcheck (valgrind-3.4.1): <<<< vex x86->IR: unhandled instruction bytes: 0xF3 0xF 0xBD 0xC0 ==20580== valgrind: Unrecognised instruction at address 0x8205141. >>>> Disassembly with gdb 6.8-6 shows the instruction to be "lzcnt %eax,%eax": <<<< (gdb) disassemble 0x8205141 Dump of assembler code for function _ZSt4__lgi: 0x0820513b <_ZSt4__lgi+0>: push %ebp 0x0820513c <_ZSt4__lgi+1>: mov %esp,%ebp 0x0820513e <_ZSt4__lgi+3>: mov 0x8(%ebp),%eax 0x08205141 <_ZSt4__lgi+6>: lzcnt %eax,%eax 0x08205145 <_ZSt4__lgi+10>: mov %eax,%edx 0x08205147 <_ZSt4__lgi+12>: mov $0x1f,%eax 0x0820514c <_ZSt4__lgi+17>: sub %edx,%eax 0x0820514e <_ZSt4__lgi+19>: leave 0x0820514f <_ZSt4__lgi+20>: ret End of assembler dump. >>>> The executable was compiled with GCC 4.3.2 with arch flags <<<< -march=amdfam10 -mcx16 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 -mtune=amdfam10 -mfpmath=sse >>>> the result of "-mtune=native -march=native -mfpmath=sse" on a AMD Athlon 7550 Dual-Core Processor. Getting rid of the "-m" flags gets rid of the problem, and there were no warnings about jumps based on uninitialized memory, so it seems to be a problem with the op-code. More (probably irrelevant) information: it happens during std::sort(), specifically std::__lg(int): <<<< inline int __lg(int __n) { return sizeof(int) * __CHAR_BIT__ - 1 - __builtin_clz(__n); } >>>> I found the problem when compiling without any -O flags; it doesn't happen if compiled with -O2. I haven't tested if it occurs with -O1 or not.
*** Bug 227551 has been marked as a duplicate of this bug. ***
*** Bug 241290 has been marked as a duplicate of this bug. ***
We should fix this, because it AMD Phenoms are pretty common. It's not terribly difficult -- it mainly requires writing a test program to find out how the hardware behaves. Does anyone have a Phenom box I can ssh into for a couple of hours, in order to write such a test?
I think machines which support this should be identifiable by "abm" in the CPU feature flags in /proc/cpuinfo.
*** Bug 240639 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > We should fix this, because it AMD Phenoms are pretty common. > It's not terribly difficult -- it mainly requires writing a test > program to find out how the hardware behaves. > > Does anyone have a Phenom box I can ssh into for a couple of hours, > in order to write such a test? I have access to a Phenom 940 (SSE4a abm enabled) running 32 bit 2.6.34.1 kernel glibc 2.11.2, gcc 4.5.0 and binutils 2.20.1. Firewall restictions at the machines location prevents external access, however I am willing to act as proxy to build/test/gather the information you seek if that would help.
For reference, the flags output of /proc/cpuinfo on the machine with the problem (which includes the abm flag): flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs
(In reply to comment #7) > For reference, the flags output of /proc/cpuinfo on the machine with the > problem (which includes the abm flag): > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 > clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm > 3dnowext 3dnow constant_tsc nonstop_tsc extd_apicid pni monitor cx16 popcnt > lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch > osvw ibs A Phenom 940 system (with this problem) reports the following flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt npt lbrv svm_lock nrip_sav
Fixed, vex r1994, with thanks to TomH for providing access to a suitable box.
Followup commits: valgrind r11241 and vex r1995.
I believe this is fixed now. It wasn't straightforward and so I'd appreciate if one of the reporters can check it works for them.
(In reply to comment #11) > I believe this is fixed now. It wasn't straightforward and so I'd > appreciate if one of the reporters can check it works for them. Latest SVN Valgind ran ok with the first program I tried but failed as follows with a second program (on Phenom 940): ==10308== Memcheck, a memory error detector ==10308== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==10308== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info ==10308== Command: ./QtPrint ==10308== ==10308== Syscall param writev(vector[...]) points to uninitialised byte(s) ==10308== at 0x4AA1555: writev (in /lib/libc-2.11.2.so) ==10308== by 0x4CA4EDC: _xcb_conn_wait (in /usr/lib/libxcb.so.1.1.0) ==10308== Address 0x4e51f4e is 94 bytes inside a block of size 16,384 alloc'd ==10308== at 0x4026153: calloc (vg_replace_malloc.c:467) ==10308== by 0x47646F2: XOpenDisplay (in /usr/lib/libX11.so.6.3.0) ==10308== ==10308== Invalid read of size 8 ==10308== at 0x42CAFED: QPointArray::shortPoints(int, int) const (in /opt/qt-3.3.8b/lib/libqt-mt.so.3.3.8) ==10308== Address 0x73c60a4 is 60 bytes inside a block of size 64 alloc'd ==10308== at 0x40276A2: malloc (vg_replace_malloc.c:236) ==10308== by 0x4559D56: QGArray::QGArray(int) (in /opt/qt-3.3.8b/lib/libqt-mt.so.3.3.8) ==10308== --10308-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --10308-- si_code=80; Faulting address: 0x0; sp: 0x62d93cbc valgrind: the 'impossible' happened: Killed by fatal signal ==10308== at 0x38050570: evalCfiExpr (debuginfo.c:1955) ==10308== by 0x380534D6: vgPlain_use_CF_info (debuginfo.c:2158) ==10308== by 0x3803C748: vgPlain_get_StackTrace_wrk (m_stacktrace.c:185) ==10308== by 0x3803C8BD: vgPlain_get_StackTrace (m_stacktrace.c:737) ==10308== by 0x38025729: record_ExeContext_wrk (m_execontext.c:316) ==10308== by 0x38001E4F: vgMemCheck_new_block (mc_malloc_wrappers.c:215) ==10308== by 0x38002186: vgMemCheck___builtin_vec_new (mc_malloc_wrappers.c:256) ==10308== by 0x3806762A: vgPlain_scheduler (scheduler.c:1384) ==10308== by 0x38078C34: run_a_thread_NORETURN (syswrap-linux.c:94) sched status: running_tid=1 Thread 1: status = VgTs_Runnable Segmentation fault ==10330== Invalid write of size 4 ==10330== at 0x422825F: QPrinter::cmd(int, QPainter*, QPDevCmdParam*) (in /opt/qt-3.3.8b/lib/libqt-mt.so.3.3.8) ==10330== Address 0x4fabc9c is 0 bytes after a block of size 12 alloc'd ==10330== at 0x4026D91: operator new[](unsigned int) (vg_replace_malloc.c:299) ==10330== by 0x4228186: QPrinter::cmd(int, QPainter*, QPDevCmdParam*) (in /opt/qt-3.3.8b/lib/libqt-mt.so.3.3.8) ==10330== Is this associated with this issue or is it something else ?
(In reply to comment #12) > Latest SVN Valgind ran ok with the first program I tried but failed as follows > with a second program (on Phenom 940): I suspect the segfault might be due to the two errors reported, especially the out-of-range write: > ==10308== Invalid read of size 8 > ==10308== at 0x42CAFED: QPointArray::shortPoints(int, int) const (in > /opt/qt-3.3.8b/lib/libqt-mt.so.3.3.8) > ==10308== Address 0x73c60a4 is 60 bytes inside a block of size 64 alloc'd > ==10308== at 0x40276A2: malloc (vg_replace_malloc.c:236) > ==10308== by 0x4559D56: QGArray::QGArray(int) (in > /opt/qt-3.3.8b/lib/libqt-mt.so.3.3.8) > ==10330== Invalid write of size 4 > ==10330== at 0x422825F: QPrinter::cmd(int, QPainter*, QPDevCmdParam*) (in > /opt/qt-3.3.8b/lib/libqt-mt.so.3.3.8) > ==10330== Address 0x4fabc9c is 0 bytes after a block of size 12 alloc'd > ==10330== at 0x4026D91: operator new[](unsigned int) > (vg_replace_malloc.c:299) > ==10330== by 0x4228186: QPrinter::cmd(int, QPainter*, QPDevCmdParam*) (in > /opt/qt-3.3.8b/lib/libqt-mt.so.3.3.8) > ==10330== If Valgrind continues to segfault once you have fixed these two errors then that would indeed be a cause for concern.
*** Bug 180217 has been marked as a duplicate of this bug. ***
*** Bug 212511 has been marked as a duplicate of this bug. ***