On some implementations, the main heap is allocated by using the brk system call.
This type of allocation is correctly managed by MemTrace.
However, besides happening quite rarely, sometimes it is possible that a program uses brk also during a call to free to deallocate memory and therefore reduce program's data segment.
If, after such a call to free, the program allocates memory again using brk and an uninitialized read accesses some location that was previously removed, the reported overlap will be incoherent.
Indeed, MemTrace will add in the access set of the uninitialized read the overlapping writes happened before the use of brk deallocated memory.
But when brk is used to allocate again some memory, it is allocated as filled with 0.
The only way to fix this would be remove all the writes accessing memory beyond the reduced data segment, so that when brk is used to increase it again, the memory it allocates is considered as uninitialized and never written before.
On some implementations, the main heap is allocated by using the brk system call.
This type of allocation is correctly managed by MemTrace.
However, besides happening quite rarely, sometimes it is possible that a program uses brk also during a call to free to deallocate memory and therefore reduce program's data segment.
If, after such a call to free, the program allocates memory again using brk and an uninitialized read accesses some location that was previously removed, the reported overlap will be incoherent.
Indeed, MemTrace will add in the access set of the uninitialized read the overlapping writes happened before the use of brk deallocated memory.
But when brk is used to allocate again some memory, it is allocated as filled with 0.
The only way to fix this would be remove all the writes accessing memory beyond the reduced data segment, so that when brk is used to increase it again, the memory it allocates is considered as uninitialized and never written before.