On 01/09/2022 01:03, Bresalier, Rob (Nokia - US/Murray Hill) wrote:
Don't understand why strace log has exit(0) without the underscore, I know for
a fact that it was with the underscore.
Because exit() and _exit() are C library functions but both call
the SYS_exit system call and that is what
> 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.
> What
On Wed, 2022-08-31 at 17:42 +, Bresalier, Rob (Nokia - US/Murray Hill)
wrote:
> > 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 l
> 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
>
> > Is there anything that can be done with memcheck to make it consume less
> > memory?
>
> No.
In fact, Yes :).
Or more precisely, yes, memory can be somewhat reduced :).
See my other mail.
Philippe
___
Valgrind-users mailing list
Valgrind-use
On Fri, 2022-08-05 at 15:34 +, Bresalier, Rob (Nokia - US/Murray Hill)
wrote:
> > 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 b
Is there anything that can be done with memcheck to make it consume less memory?
First of all, figure out whether memcheck got sigkilled because the machine
ran out of space, or because you hit some shell limit/ulimit. In the former
case, you can then try adding swap space to the machine. I
Is there anything that can be done with memcheck to make it consume less memory?
No.
Well, you can use the command-line argument "--num-callers=" to reduce
the length
of tracebacks that are stored in the "red zones" just before and after an
allocated block.
This might help enough if you have
Does heaptrack also show the 'still reachable' types of leaks that memcheck
does?
Heaptrack intercepts malloc+free+etc, then logs the parameters, result, and
traceback; but otherwise lets the progcess-original malloc+free+etc do the work.
Heaptrack does not notice, and does not care, what you
> > 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 +++", but
Thanks Tom.
Do you think I'd have better luck using the "massif" tool? Would "massif" be
able to avoid the OOM killer?
Or is there a way to reduce the amount of memory that memcheck will use?
-Original Message-
From: Tom Hughes
Sent: Friday, August 5, 2022 10:08 AM
To: Bresalier, Rob
> 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
On 05/08/2022 16:08, Tom Hughes via Valgrind-users wrote:
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.
Or possibly watch `dmesg -w` running in another shell.
J
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.
If finding memory leaks is the only goal (for instance, if you are
On 05/08/2022 14:09, Bresalier, Rob (Nokia - US/Murray Hill) wrote:
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 printe
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
16 matches
Mail list logo
