| Summary: | unhandled instruction bytes: 0xF3 0xF 0xBD 0xC0 (lzcnt %eax,%eax) | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Matthew Cline <matt> |
| Component: | vex | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | alexanders83, ashl1future, asp, b.buschinski, manolis, smf.linux, tom |
| Priority: | NOR | ||
| Version: | 3.4.1 | ||
| Target Milestone: | --- | ||
| Platform: | Mandriva RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Matthew Cline
2009-10-30 00:19:04 UTC
*** 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. *** |