I'm using Valgrind 3.7.0, compiled from source code, on Ubuntu 12.04 x64 server edition. CPU is Intel Xeon. When I'm testing oggenc 1.0.1, Valgrind halts with following information: ==13553== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==13553== Command: ../../utest/bin64/oggenc101 ../../utest/test.wav -o ../../utest/test.ogg ==13553== Opening with wav module: WAV file reader vex amd64->IR: unhandled instruction bytes: 0xF 0xB 0xF 0x1F 0x0 0x40 0x38 0xFE vex amd64->IR: unhandled instruction bytes: 0xF 0xB 0xF 0x1F 0x0 0x40 0x38 0xFE vex amd64->IR: unhandled instruction bytes: 0xF 0xB 0xF 0x1F 0x0 0x40 0x38 0xFE vex amd64->IR: unhandled instruction bytes: 0xF 0xB 0xF 0x1F 0x0 0x40 0x38 0xFE vex amd64->IR: unhandled instruction bytes: 0xF 0xB 0xF 0x1F 0x0 0x40 0x38 0xFE vex amd64->IR: unhandled instruction bytes: 0xF 0xB 0xF 0x1F 0x0 0x40 0x38 0xFE vex amd64->IR: unhandled instruction bytes: 0xF 0xB 0xF 0x1F 0x0 0x40 0x38 0xFE vex amd64->IR: unhandled instruction bytes: 0xF 0xB 0xF 0x1F 0x0 0x40 0x38 0xFE vex amd64->IR: unhandled instruction bytes: 0xF 0xB 0xF 0x1F 0x0 0x40 0x38 0xFE vex amd64->IR: unhandled instruction bytes: 0xF 0xB 0xF 0x1F 0x0 0x40 0x38 0xFE .....[thousands of lines with the same content omitted] vex amd64->IR: unhandled instruction bytes: 0xF 0xB 0xF 0x1F 0x0 0x40 0x38 0xFE vex amd64->IR: unhandled instruction bytes: 0xF 0xB 0xF 0x1F 0x0 0x40 0x38 0xFE vex amd64->IR: unhandled instruction bytes: 0xF 0xB 0xF 0x1F 0x0 0x40 0x38 0xFE vex amd64->IR: unhandled instruction bytes: 0xF 0xB 0xF 0x1F 0x0 0x40 0x38 0xFE vex amd64->IR: unhandled instruction bytes: 0xF 0xB 0xF 0x1F 0x0 0x40 0x38 0xFE vex amd64->IR: unhandled instruction bytes: 0xF 0xB 0xF 0x1F 0x0 0x40 0x38 0xFE VEX temporary storage exhausted. Pool = TEMP, start 0x3a80bc40 curr 0x3acd0778 end 0x3acd077f (size 5000000) vex: the `impossible' happened: VEX temporary storage exhausted. Increase N_{TEMPORARY,PERMANENT}_BYTES and recompile. vex storage: T total 138272976 bytes allocated vex storage: P total 960 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). ==13553== at 0x3802E806: report_and_quit (m_libcassert.c:210) ==13553== by 0x3802E863: panic (m_libcassert.c:294) ==13553== by 0x3802EA18: vgPlain_core_panic_at (m_libcassert.c:299) ==13553== by 0x3802EA2A: vgPlain_core_panic (m_libcassert.c:304) ==13553== by 0x38043A22: failure_exit (m_translate.c:701) ==13553== by 0x380C9828: vpanic (main_util.c:226) ==13553== by 0x380C98F9: private_LibVEX_alloc_OOM (main_util.c:171) ==13553== by 0x380CF529: emptyIRSB (libvex.h:358) ==13553== by 0x380D27B5: flatten_BB (ir_opt.c:481) ==13553== by 0x380D8E25: do_iropt_BB (ir_opt.c:4724) ==13553== by 0x380C804C: LibVEX_Translate2 (main_main.c:569) ==13553== by 0x38043580: translate (m_translate.c:1576) ==13553== by 0x38045A59: vgPlain_translate_ahead (m_translate.c:1686) ==13553== by 0x38028494: ctrl_instrument (pd_ctrl.c:700) ==13553== by 0x3802B17C: pd_instrument (pd_main.c:791) ==13553== by 0x38043979: tool_instrument_then_gdbserver_if_needed (m_translate.c:227) ==13553== by 0x380C80A2: LibVEX_Translate2 (main_main.c:587) ==13553== by 0x380C8C3D: LibVEX_Translate (main_main.c:766) ==13553== by 0x380430C1: translate (m_translate.c:1574) ==13553== by 0x380459D8: vgPlain_translate (m_translate.c:1664) ==13553== by 0x38070758: vgPlain_scheduler (scheduler.c:901) ==13553== by 0x38080785: run_a_thread_NORETURN (syswrap-linux.c:98) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==13553== at 0x5067790: __memcpy_ssse3_back (memcpy-ssse3-back.S:60) ==13553== by 0x407837: create_directories (oggenc_1.0.1.c:3129) ==13553== by 0x401E00: main (oggenc_1.0.1.c:938) 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. ----- I searched bug list and also other places on Internet, many similar issues raised but no one exactly with the same instruction bytes 0xF 0xB 0xF 0x1F 0x0 0x40 0x38 0xFE.
The first two bytes 0xF 0xB are 'ud2', which is the official two-byte "undefined opcode"; all following bytes "0xF 0x1F 0x0 0x40 0x38 0xFE" are not relevant. From the point of view of the app, then the real error happened some time ago; the ud2 is just "I give up". So, this bug will become a slog to scan backwards (logically, in the execution history) to find the place where the real error occurred. Valgrind should recognize ud2 for what it is, and not confuse itself and the user. Handle the instruction bytes 0xF 0xB as "fatal error."
> Valgrind should recognize ud2 for what it is, and not confuse itself and the user. Yes, it should .. parse it and generate IR to throw a SIGILL. Strange that that has never been properly fixed so far.
*** This bug has been marked as a duplicate of bug 254088 ***