> Normally, if it is the OOM that kills a process, you should find a trace of
> this in the system logs.
I looked in every system log I could find, there was no indication of OOM
killing it in any system log.
> I do not understand what you mean by reducing the nr of callers from 12 to 6.
>
> When running memcheck on a massive monolith embedded executable
> (237MB stripped, 1.8GiB unstripped), after I stop the executable under
> valgrind I see the "HEAP SUMMARY" but then valgrind dies before any leak
> reports are printed. The parent process sees that the return status of
> memcheck
I tried 'massif' on a simple program shown below where there are "definitely
lost" leaks.
massif doesn't seem to find "definitely lost" leaks, is this correct?
I'm tried with both 3.19.0 and 3.15.0 versions of valgrind/massif, same result,
"definitely lost" leaks are not found.
I launch
> > If you want to know for sure who killed it then strace it while it
> > runs and it should show you who sends the signel but my bet is that
> > it's the kernel.
>
I tried strace -p on my process before I triggered its exit. The strace
output ends saying with: "+++ killed by SIGKILL +++",
M
To: Bresalier, Rob (Nokia - US/Murray Hill) ;
valgrind-users@lists.sourceforge.net
Subject: Re: memcheck is getting SIGKILLed before leak report is output
On 05/08/2022 14:09, Bresalier, Rob (Nokia - US/Murray Hill) wrote:
> When running memcheck on a massive monolith embedded executable (23
> If finding memory leaks is the only goal (for instance, if you are satisfied
> that
> memcheck has found all the overrun blocks, uninitialized reads, etc.) then
> https://github.com/KDE/heaptrack is the best tool.
Thanks! I didn't know about heaptrack. I will look definitely into that. Does
When running memcheck on a massive monolith embedded executable (237MB
stripped, 1.8GiB unstripped), after I stop the executable under valgrind I see
the "HEAP SUMMARY" but then valgrind dies before any leak reports are printed.
The parent process sees that the return status of memcheck is that
We are trying to track down a suspected place in our code that keeps
accumulating memory in a 'still reachable'.
When I turn on still reachable and run my process for a few hours and then stop
the process to get the valgrind reports there are over 2.7 million loss records
which are mostly
