Comment 29 for bug 1042946

Laurynas, interesting proposal. If further "Log_event::read_log_event" analysis turns out to be a dead road (unlikely I suspect), then Massif may help.

For others who are reading this; the type of issues that Massif finds is completely different:

Massif will detect unused blocks for which pointers remain valid:

'Also, there are certain space leaks that aren't detected by traditional leak-checkers, such as Memcheck's. ** That's because the memory isn't ever actually lost -- a pointer remains to it -- but it's not in use. **Programs that have leaks like this can unnecessarily increase the amount of memory they are using over time.** Massif can help identify these leaks. Importantly, Massif tells you not only how much heap memory your program is using, it also gives very detailed information that indicates which parts of your program are responsible for allocating the heap memory. ' (http://valgrind.org/docs/manual/ms-manual.html)

While Memcheck finds issues for which pointers are already lost (as in our case with Log_event::read_log_event):

'Definitely lost: [...] This means that no pointer to the block can be found. The block is classified as "lost", because the programmer could not possibly have freed it at program exit, since no pointer to it exists. This is likely a symptom of having lost the pointer at some earlier point in the program. Such cases should be fixed by the programmer.' (http://valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks)

Analyzing "Log_event::read_log_event" further would be the first step.