derekbruening
commented
9 years ago From rnk@google.com on November 02, 2011 14:57:57
In r1117 , this assert was relaxed to a curiosity, so it will only create noise for developers running debug builds with real data structures that contain 0xcdcdcdcd. For everyone else, it should serve as a useful warning that a double free occurred. This issue still covers removing the curiosity completely and replacing it with something 100% reliable.
Owner: rnk@google.com
Labels: -Priority-Medium Priority-Low Bug-Assert
From reid.kle...@gmail.com 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