I was testing the malloctrace example shown on the official Intel PIN website: https://software.intel.com/sites/landingpage/pintool/docs/98484/Pin/html/index.html#FunctionArguments
I have a very simple testing binary file with the source code of:
int main()
{
char *buf = malloc(sizeof(char)*50);
//printf("Buf addr: %p\n", buf); // sanity check
char *bar_buf = malloc(sizeof(char)*50);
//printf("Bar_buf addr: %p\n", bar_buf); // sanity check
free(buf);
free(bar_buf);
}
Upon executing the above malloctrace example with this simple binary file, the output looks like this:
...
malloc(0x32) <- first malloc
malloc(0x32) <- second malloc
returns 0x55cb2b4222e0
free(0x55cb2b4222a0) <- free of first malloc
free(0x55cb2b4222e0) <- free of second malloc
Interestingly enough, for whatever reason, the first malloc does not return the address it obtains from the malloc call, similar to what is shown for the second malloc.
What I am expecting is the return value for the first malloc is 0x55cb2b4222a0 as that is the input argument to the free(buf) for the test source code.
I have done some additional instrumentation and testing (such as checking all read/write to the memory location) to conclude that this is simply that Intel PIN cannot find the proper instrumentation point to insert the profiling code after the first malloc, but I was nevertheless wondering if anyone else had to face this issue, and potentially know the solution to solving this "missing instrumentation" problem.
