3. How much physical RAM? How much swap space? (The string "out_of_memory"
appears in the output.)
JK - [ 0.000000] Memory: 495376K/507904K available (5078K kernel code, 420K
rwdata, 1704K rodata, 208K init, 328K bss, 12528K reserved, 0K highmem)
Not sure how to get swap space.
Run /usr/bin/top, which gives other useful statistics about resources, too.
On a 32-bit ARM RaspberryPi model 2 with 1GB RAM the output might begin like
this
for an "idle" machine:
=====
Tasks: 84 total, 1 running, 83 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.1 us, 0.1 sy, 0.0 ni, 99.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 924.1 total, 582.1 free, 66.0 used, 276.0 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 830.5 avail Mem
=====
4. Was valgrind essentially the only process running?
JK – Definitely not. The TR069 consists of a whole family of CCSP processes
that communicate to each other via DBUS. The TR069PA was however the only
process running via valgrind
5. How many threads?
JK – 4 threads per CCSP process, including the one running valgrind.
So there are many CCSP processes, plus other processes, running on a box with
512 megaBytes of RAM and no swap space. Remember that a process running
valgrind
(memcheck) requires about 2 to 3 times the memory of a non-checked process.
You have exhausted the available RAM. The "out of memory" string was a clue.
Reduce the number and size of simultaneous CCSP processes. Reduce the number
and size non-CCSP processes. Run valgrind (memcheck) only on the one CCSP
process that really interests you. Do not use --trace-children=yes. Instead,
make CcspTr069PaSsp into an executable "wrapper" shell script which identifies
the correct instance (perhaps by count of invocations), then runs valgrind
on a saved copy of the original CcspTr069PaSsp; else just runs the
saved copy without valgrind.
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
