Bug 301902 - vex amd64->IR: unhandled instruction bytes: 0xF 0xB 0xF 0x1F 0x0 0x40 0x38 0xFE
Summary: vex amd64->IR: unhandled instruction bytes: 0xF 0xB 0xF 0x1F 0x0 0x40 0x38 0xFE
Status: RESOLVED DUPLICATE of bug 254088
Alias: None
Product: valgrind
Classification: Developer tools
Component: vex (show other bugs)
Version: 3.7.0
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-14 13:25 UTC by Rico
Modified: 2012-07-05 09:04 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rico 2012-06-14 13:25:59 UTC
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.
Comment 1 John Reiser 2012-06-30 21:55:12 UTC
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."
Comment 2 Julian Seward 2012-07-05 09:02:17 UTC
> 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.
Comment 3 Tom Hughes 2012-07-05 09:04:54 UTC

*** This bug has been marked as a duplicate of bug 254088 ***