Re: Application doesn't leak memory running valgrind

Stefano Antonelli <[email protected]>
Newsgroups gmane.comp.debugging.valgrind
Message-ID <[email protected]>
On Mon, 2022-02-28 at 13:11 -0800, Stefano Antonelli wrote:
> When the leak occurs, the number of 4k pages owned by this render
> device increases.  Running valgrind leak-test (or gdb with malloc
> breakpoint), the number of 4k pages owned by this render device _do
> not_ increase.

When I run callgrind, the same behaviour happens.

valgrind  --tool=callgrind --instr-atstart=no ./qml-mwe3

Once the application is up and running, I use:

:~# callgrind_control --instr=on 4120
PID 4120: ./qml-mwe3
sending command instrumentation on to pid 4120
  OK.
:~# callgrind_control -s 4120
PID 4120: ./qml-mwe3
sending command status internal to pid 4120
  Number of running threads: 4, thread IDs: 1 2 3 4
  Events collected: Ir
  Functions: 1,104 (executed 1,289, contexts 1,104)
  Basic blocks: 1,816 (executed 1,120,586,516, call sites 452)

:~# callgrind_control --instr=off 4120
PID 4120: ./qml-mwe3
sending command instrumentation off to pid 4120
  OK.

After the I turn on the instrumentation, the display stops updating
completely (it's running an animation).  Once I turn off the
instrumentation, the display resumes.  I would expect the animation to
run dreadfully slow, but not freeze in place for the duration of time
instrumentation was on.  I don't know exactly how much time this was,
but if I had to guess I'd say around 10 minutes.

I should also add that the processor is armhf and I noticed with
callgrind I get a couple of warnings:

==4120== Callgrind, a call-graph generating cache profiler
==4120== Copyright (C) 2002-2017, and GNU GPL'd, by Josef Weidendorfer
et al.
==4120== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright
info
==4120== Command: ./qml-mwe3
==4120== 
==4120== For interactive control, run 'callgrind_control -h'.
==4120== Warning: noted but unhandled ioctl 0x6443 with no
size/direction hints.
==4120==    This could cause spurious value errors to appear.
==4120==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing
a proper wrapper.
==4120== Warning: noted but unhandled ioctl 0x4b51 with no
size/direction hints.
==4120==    This could cause spurious value errors to appear.
==4120==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing
a proper wrapper.
disInstr(thumb): unhandled instruction: 0xDEFF 0xF8DD

I don't know if that's breaking things or not.  Nor do I know what
these IOCTLs are, but I am trying to
parse README_MISSING_SYSCALL_OR_IOCTL as I go along here.

-Stef
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.