From: John R. <jr...@bi...> - 2020-01-31 05:56:34
|
> 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. |