Bug 438640

Summary:	vex x86->IR: unhandled instruction bytes: 0xF2 0xF 0x38 0xF1
Product:	[Developer tools] valgrind	Reporter:	amita dwivedi <amita1612>
Component:	memcheck	Assignee:	Julian Seward <jseward>
Status:	REPORTED ---
Severity:	normal	CC:	tom
Priority:	NOR
Version First Reported In:	3.15 SVN
Target Milestone:	---
Platform:	Other
OS:	Other
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description amita dwivedi 2021-06-14 17:48:42 UTC

SUMMARY
Getting below error when running valgrind while sending traffic.

vex x86->IR: unhandled instruction bytes: 0xF2 0xF 0x38 0xF1

valgrind: Unrecognised instruction at address 0xABCDE8.

at 0xABCDE8: clib_bihash_add_del_40_8_32 (smmintrin.h:815)
  

 Process terminating with default action of signal 4 (SIGILL): dumping core

Illegal opcode at address 0xABCDE8

STEPS TO REPRODUCE
1. Bring up the subscriber
2. Send traffic by ping
3. Crash will be observed

OBSERVED RESULT

Crash

EXPECTED RESULT
It should not crash

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma:  : Linux
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION

Comment 1 Tom Hughes 2021-06-14 18:06:48 UTC

That is the CRC32 instruction, which I think probably qualifies as an extremely obscure corner of the x86 instruction set...

Comment 2 amita dwivedi 2021-06-14 18:13:57 UTC

Is it Valgrind doesn't support these instructions? How we can fix it to avoid crash

Comment 3 Tom Hughes 2021-06-14 18:14:56 UTC

Yes valgrind doesn't support it currently - it's so obscure apparently nobody has run into it before.

Comment 4 amita dwivedi 2021-06-29 11:17:12 UTC

Could you please let me know if there is a way to fix the crash while sending traffic with valgrind enabled. 

 vex x86->IR: unhandled instruction bytes: 0xF2 0xF 0x38 0xF1
 valgrind: Unrecognised instruction at address 0x9c7bea8.
 at 0x9C7BEA8: clib_bihash_add_del_40_8_32 (smmintrin.h:815)

Comment 5 amita dwivedi 2021-06-29 11:20:03 UTC

2021-Jun-29+04:17:54.678 card 1-cpu0: ==9231== Your program just tried to execute an instruction that Valgrind

 2021-Jun-29+04:17:54.678 card 1-cpu0: ==9231== did not recognise.  There are two possible reasons for this.

 2021-Jun-29+04:17:54.678 card 1-cpu0: ==9231== 1. Your program has a bug and erroneously jumped to a non-code

 2021-Jun-29+04:17:54.678 card 1-cpu0: ==9231==    location.  If you are running Memcheck and you just saw a

 2021-Jun-29+04:17:54.678 card 1-cpu0: ==9231==    warning about a bad jump, it's probably your program's fault.

 2021-Jun-29+04:17:54.678 card 1-cpu0: ==9231== 2. The instruction is legitimate but Valgrind doesn't handle it,

 2021-Jun-29+04:17:54.678 card 1-cpu0: ==9231==    i.e. it's Valgrind's fault.  If you think this is the case or

 2021-Jun-29+04:17:54.678 card 1-cpu0: ==9231==    you are not sure, please let us know and we'll try to fix it.

 2021-Jun-29+04:17:54.678 card 1-cpu0: ==9231== Either way, Valgrind will now raise a SIGILL signal which will

 2021-Jun-29+04:17:54.678 card 1-cpu0: ==9231== probably kill your program.

 2021-Jun-29+04:17:54.678 card 1-cpu0: ==9231== 

 2021-Jun-29+04:17:54.678 card 1-cpu0: ==9231== Process terminating with default action of signal 4 (SIGILL): dumping core

 2021-Jun-29+04:17:54.678 card 1-cpu0: ==9231==  Illegal opcode at address 0x9C7BEA8

 2021-Jun-29+04:17:54.678 card 1-cpu0: ==9231==    at 0x9C7BEA8: clib_bihash_add_del_40_8_32 (smmintrin.h:815)

Comment 6 Tom Hughes 2021-06-29 11:24:12 UTC

The only way to avoid the crash, other that fixing valgrind to handle that instruction is to change your code not to use it, either by changing your compiler options to target a different CPU or by removing that instruction from any assembly code that uses it.

Comment 7 amita dwivedi 2021-06-29 17:12:39 UTC

Is it possible to fix in valgrind by applying some patch ?

Comment 8 Tom Hughes 2021-06-29 17:30:28 UTC

If somebody writes a patch to implement support for that instruction then sure.