Mallocs performed before enty point execution

[kristopher-pellizzi]

Sometimes, it is possible that some mallocs happen before the entry point is executed (probably due to some library initialization).
The tool starts tracing memory accesses from the entry point, until program termination.
This caused mainly 2 problems:

• If the program accessed some of the heap areas allocated before the entry point, those accesses were always considered as uninitialized, regardless of the real state, thus causing many false positives.
• If many allocations were performed before the entry point, it was possible that some heap accesses did not have a corresponding shadow memory. So, when the program tried to access it, a segmentation fault was raised.

In order to solve these problems, now the tool always keep track of mallocs and frees, but heap areas allocated before the entry point are only partially traced. Indeed, the tool still does not trace accesses performed there before the entry point is executed, but it simply assumes that any malloc performed before that initialized the whole chunk, and that frees de-initialize it. This way, we are solving the occasional segmentation faults, and we are mitigating the false positives problem.
This latter one is not completely solved, because if some chunk is freed before the entry point, it is possible that the program will reallocate it through a call to malloc. In glibc malloc, the function reads from inside the chunk to be allocated to check if there's any metadata left by the previous free. Since the free preceding the entry point simply reset the whole chunk as uninitialized, this access will generate an uninitialized read in the reports. However, this will not have any overlapping write.