On 8/5/2022 8:47 PM, G N Srinivasa Prasanna wrote:
Thanks for this information.
We are doing a memory system simulation, and need the address stream. At this point of time, we
don't care if we need a Terabyte even, we can delete the files later.
Is there anything we can use from Valgrind?
Thanks, will check it out.
Best
From: Eliot Moss
Sent: 06 August 2022 07:10
To: G N Srinivasa Prasanna ; John Reiser
; valgrind-users@lists.sourceforge.net
Subject: Re: [Valgrind-users] Valgrind trace Memory Addresses while running?
On 8/5/2022 8:47 PM, G N
Thanks for this information.
We are doing a memory system simulation, and need the address stream. At this
point of time, we don't care if we need a Terabyte even, we can delete the
files later.
Is there anything we can use from Valgrind?
Best
From: John
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 we can get a list of all the physical addresses the program used, in the
order the program accessed them, and whether read/write.
For any real world application the size of the log would be overwhelmingly
huge ... (unless you only want unique addresses).
Of course this is the purpose
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
> On 5 Aug 2022, at 20:53, G N Srinivasa Prasanna
> wrote:
>
>
> This is the first time we are using Valgrind, and we want to know if we can
> get a list of all the physical addresses the program used, in the order the
> program accessed them, and whether read/write.
>
> Please let us
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 +++",
This is the first time we are using Valgrind, and we want to know if we can get
a list of all the physical addresses the program used, in the order the program
accessed them, and whether read/write.
Please let us know if we can get this from Valgrind - the webpage information
is not clear.
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
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
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
