CheckOpCodes Exception in TBB 4.4U3 x64

[Luke_V_]

We recently updated from 4.4 to 4.4U3 and are now getting

Assertion false failed on line 234 of file ../../src/tbbmalloc/tbb_function_replacement.cpp
Detailed description: CheckOpcodes failed

on program start. Here is the stack:

 	tbbmalloc_proxy_debug.dll!rml::internal::assertion_failure(const char * filename, int line, const char * expression, const char * comment) Line 72	C++
 	tbbmalloc_proxy_debug.dll!CheckOpcodes(const char * * opcodes, void * inpAddr) Line 237	C++
 	tbbmalloc_proxy_debug.dll!InsertTrampoline32(void * inpAddr, void * targetAddr, const char * * opcodes, void * * storedAddr) Line 257	C++
 	tbbmalloc_proxy_debug.dll!InsertTrampoline(void * inpAddr, void * targetAddr, const char * * opcodes, void * * origFunc) Line 372	C++
>	tbbmalloc_proxy_debug.dll!ReplaceFunctionA(const char * dllName, const char * funcName, void (void) * newFunc, const char * * opcodes, void (void) * * origFunc) Line 422	C++
 	tbbmalloc_proxy_debug.dll!ReplaceFunctionWithStore(const char * dllName, const char * const funcName, void (void) * newFunc, const char * const * opcodes, void (void) * * origFunc, FRR_ON_ERROR on_error) Line 538	C++
 	tbbmalloc_proxy_debug.dll!doMallocReplacement() Line 559	C++
 	tbbmalloc_proxy_debug.dll!DllMain(HINSTANCE__ * hInst, unsigned long callReason, void * reserved) Line 607	C++
 	tbbmalloc_proxy_debug.dll!__DllMainCRTStartup(void * hDllHandle, unsigned long dwReason, void * lpreserved) Line 508	C
 	tbbmalloc_proxy_debug.dll!_DllMainCRTStartup(void * hDllHandle, unsigned long dwReason, void * lpreserved) Line 473	C
 	ntdll.dll!00007ffbaadb52c8()	Unknown
 	ntdll.dll!00007ffbaae120ca()	Unknown
 	ntdll.dll!00007ffbaae11f0f()	Unknown
 	ntdll.dll!00007ffbaae11f2d()	Unknown
 	ntdll.dll!00007ffbaae300fe()	Unknown
 	ntdll.dll!00007ffbaae6166d()	Unknown
 	ntdll.dll!00007ffbaae16d5e()	Unknown

Our main.cpp has the following include:

#include "tbb/tbbmalloc_proxy.h"

Inserttrampoline has the following locals:

+		dllName	0x00007ffb9973c3a9 "msvcr120.dll"	const char *
+		funcName	0x00007ffb9973c3b6 "free"	const char *
		newFunc	0x00007ffb99731bd6 {tbbmalloc_proxy_debug.dll!__TBB_malloc_safer_free_msvcr120(void *)}	void (void) *
+		opcodes	0x00007ffb99738150 {tbbmalloc_proxy_debug.dll!const char  * const known_bytecodes[5]} {0x00007ffb9973c56c "4883EC384885C975"}	const char * *
+		origFunc	0x00007ffb997383c8 {tbbmalloc_proxy_debug.dll!void(*orig_free_msvcr120)(void *)} {0x0000000000000000}	void (void) * *
+		cachedName	0x00007ffb99739c40 "msvcr120.dll"	char[261]
+		cachedHM	msvcr120.dll!0x00007ffb7c940000 (load symbols for additional information) {unused=9460301 }	HINSTANCE__ *
		inpFunc	msvcr120.dll!0x00007ffb7c9a69bc (load symbols for additional information)	__int64 (void) *

CheckOpcodes has the following locals:

+		opcodes	0x00007ffb99738150 {tbbmalloc_proxy_debug.dll!const char  * const known_bytecodes[5]} {0x00007ffb9973c56c "4883EC384885C975"}	const char * *
		inpAddr	msvcr120.dll!0x00007ffb7c9a69bc (load symbols for additional information)	void *
		opcodesStringsCount	4	unsigned __int64
		maxOpcodesLength	20	unsigned __int64
		opcodes_pointer	140718588002640	unsigned __int64
+		opcodeString	0x000000e82f6fe7a8 "4885C97437534883EC20"	char[61]
		i	4	unsigned __int64
		result	0	unsigned __int64

Previously we were seeing this opcode behaviour with the x86 build, but we are now seeing it with the x64 build. We are using both Visual Studio 2013 and 2015, and QT 5.6 (with solution generation provided by qmake). Are we setting up our project incorrectly? How do we fix this exception?

[Peter_W_Intel]

Is it possible that you can provide a mini project of Visual Studio 2013 to reproduce this problem, then investigate?

[Luke_V_]

After a series of investigations, it was traced to an incompatible openSSL being linked. After a complete rebuild of openSSL the opcode exception no longer happens. It is strange that we received no errors from the linker, or at runtime and it was only TBB letting us know something was wrong. Then again, openSSL + QT has a very particular setup (read: magic) so maybe that caused it to be missed by the compiler / linker.