Bad HEAP_UNALLOCATED assert in common_heap_free

_From [reid.kle...@gmail.com](https://code.google.com/u/108532745084733145449/) on March 17, 2011 01:13:33_

On my system (one of the Debian x86_64 machines at CSAIL) while writing a test client I was able to produce instruction operands causing the common_heap_free assert that checks for HEAP_UNALLOCATED to fail. There's already a FIXME there talking about the riskiness of doing it. I think it's more likely to fail on 64-bit systems because of the RAX:RDX return value calling convention.

What happens in my case is I call opnd_create_reg, which sets .kind and .value.reg, which are both the first bytes of the two quad-words that comprise the opnd_t. Then I create a mov immediate instruction which only has one destination, so it makes an dsts array that looks like:

0x0000003900000005 0xcdcdcdcdcdcdcd01

The kind is 5 (REG_kind) and the .value.reg attr is 1 (REG_RAX). When interpreted as little endian, the last word is the magic unallocated word. The assert checks for the first two uint words of the allocation and the last word for the unallocated sentinel, and finds it in the last. If I initialize the opnd_t in opnd_create_reg, the problem goes away.

Should we remove the assert as buggy, or try harder to fully initialize opnd_t values everywhere (only in debug mode, of course)?

_Original issue: http://code.google.com/p/dynamorio/issues/detail?id=417_