Memcheck currently doesn't monitor the heap. Here is one way that it could.
Implement malloc, free, etc. in existing libc_memcheck library.
Turn around and call libc's malloc, but with larger sizes. Note: this will only work if it's deterministic for processes with the same parent. Assume it is for now.
Fill entire region in-core (just as with stack changes).
Record allocated regions in list.
At sequence point, check
- Each thread's heap buffer end regions are 00's or ff's, respectively.
Problem: how should the custom memcheck implementation get initialized? It needs to know the pointer to the fill value, but tracer doesn't know how to get a pointer to memcheck's variable for that.
Possible solution: define CUSTOM SYSTEM CALLS, where eax is some unused number. This is hacky, but it should work. malloc() would check if a field is initialized; if not, it would make this synthetic system call.
Memcheck currently doesn't monitor the heap. Here is one way that it could.
Implement
malloc,free, etc. in existinglibc_memchecklibrary.Turn around and call
libc's malloc, but with larger sizes. Note: this will only work if it's deterministic for processes with the same parent. Assume it is for now.Fill entire region in-core (just as with stack changes).
Record allocated regions in list.
At sequence point, check
Problem: how should the custom memcheck implementation get initialized? It needs to know the pointer to the fill value, but tracer doesn't know how to get a pointer to memcheck's variable for that.
Possible solution: define CUSTOM SYSTEM CALLS, where eax is some unused number. This is hacky, but it should work. malloc() would check if a field is initialized; if not, it would make this synthetic system call.