nmosier / trace-memcheck Goto Github PK

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.

Partial reads, indicating end-of-file, occur some of the time on a syscall to open().

Need to test SYS_MEMCHECK_GETFILLPTR

The pre() and pre_*() routines are unused and should be removed.

Currently, the JIT engine waits on ALL traced processes to stop before handling the breakpoint. This is because it makes changes to the code blocks in all processes, which can cause inconsistencies and race conditions depending on where the tracee's PCs are.

One solution would be to have a shared queue of "patch" objects. A tracee stopped by a JIT-bkpt can cause the patcher to add a patch to the queue. Upon stopping, each tracee will check the queue for new patches. Once all threads have applied the patch, it'll be removed from the queue. (This can be tracked with an integer, e.g.)