Hi all,
while running osmo-pcu, it appears that it is leaking memory. At startup time it consumes 4188 kBytes of virtual memory (on sysmobts-v2), while after about 8MBytes of data transfer of a single GPRS-MS over 48 hours, the virtual size has expanded to 8584 kBytes.
Now I know that VSS is not RSS, etc. - but the fact that it always only increasees, and increases with traffic is a clear indication of some leakage somewehere.
Unfortunately it also seems talloc is not used correctly in osmo-pcu, as a USR1 signal doesn't really show any allocated objects beyond two. So somehow either not all allocations are done with talloc, or the allocation hierarchy does not link the objects to the root talloc context.
Regards, Harald
Harald,
Thanks for the observation.
It would be great if this is filed to a bag tracker. Could you please setup one for osmo-pcu and create this as a ticket there?
On Tue, Jan 15, 2013 at 8:42 PM, Harald Welte laforge@gnumonks.org wrote:
Hi all,
while running osmo-pcu, it appears that it is leaking memory. At startup time it consumes 4188 kBytes of virtual memory (on sysmobts-v2), while after about 8MBytes of data transfer of a single GPRS-MS over 48 hours, the virtual size has expanded to 8584 kBytes.
Now I know that VSS is not RSS, etc. - but the fact that it always only increasees, and increases with traffic is a clear indication of some leakage somewehere.
Unfortunately it also seems talloc is not used correctly in osmo-pcu, as a USR1 signal doesn't really show any allocated objects beyond two. So somehow either not all allocations are done with talloc, or the allocation hierarchy does not link the objects to the root talloc context.
Regards, Harald
--
- Harald Welte laforge@gnumonks.org http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Harald Welte wrote:
while running osmo-pcu, it appears that it is leaking memory. At startup time it consumes 4188 kBytes of virtual memory (on sysmobts-v2), while after about 8MBytes of data transfer of a single GPRS-MS over 48 hours, the virtual size has expanded to 8584 kBytes.
hi harald,
i just pushed the fix to jolly_merge branch.
the memory leak happened for each data message from SGSN to PCU. the bitvector used for parsing ms-class was not freed.
additionally i included the bitvector's talloc context into the global PCU's talloc context, so one can find out if it leaks.
regards,
andreas
Hi Jolly,
On Wed, Jan 16, 2013 at 09:25:18AM +0100, jolly wrote:
the memory leak happened for each data message from SGSN to PCU. the bitvector used for parsing ms-class was not freed.
thanks for the quick fix.
additionally i included the bitvector's talloc context into the global PCU's talloc context, so one can find out if it leaks.
If you find the time (it's not urgent) it might be worth to audit the code to make sure that all allocations are part of the talloc context hierarchy. Given that the report only showed two allocations in the version I used yesterday, I think the ms-class bit-vector might not be the only data structure that is not properly referenced to the context. I would have expected to see at least some persistent structures like all the currently active TBFs.
Thanks in advance, Harald
Harald Welte wrote:
If you find the time (it's not urgent) it might be worth to audit the code to make sure that all allocations are part of the talloc context hierarchy. Given that the report only showed two allocations in the version I used yesterday, I think the ms-class bit-vector might not be the only data structure that is not properly referenced to the context. I would have expected to see at least some persistent structures like all the currently active TBFs.
hi harald,
the committed fix shows all bit-vector allocations in the report, not only ms-class' bit vector. additionally i checked that all allocated bit vectors are freed. (this is how i found the bug.) there is currently no other talloc (at run time) that does not use the global PCU's context, so a USR1 signal (or terminating the process) would show all leaking allocations. i just added the use of PCU's talloc context when creating libosmogb's NS instance.
regards,
andreas
Hi Andreas,
just a quick feedback: I can confirm that the memory leak is gone. I can also confirm that GPRS operation on a single timeslot is working, too. Good work!
Regards, Harald
osmocom-net-gprs@lists.osmocom.org
-
Alexander Chemeris -
Andreas Eversberg -
Harald Welte -
jolly