Bug #5340
openttcn3-msc-test: more memory leaks
20%
Description
We have talloc reports in the build artifacts starting from today:
And here one can clearly see leaked memory (MSC_Tests_Iu.TC_mo_cc_iu_release executed last):
Chunk 'bssmap: clear command'¶
msgb contains 17400 bytes in 16 blocks (ref 0) 0x563205605390 bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057a0290 bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057f30c0 bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057e39e0 bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057eca30 bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057d7740 bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057a4e50 bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057a5e80 bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057c9fe0 bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057d2120 bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057ed520 bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057ce880 bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632058004a0 bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057c8940 bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x563205800aa0 bssmap: clear command contains 1160 bytes in 1 blocks (ref 0) 0x5632057bb620
I can reproduce this leak by running MSC_Tests.TC_ho_inter_bsc manually.
Chunk 'struct sgs_connection'¶
struct osmo_stream_srv_link contains 3688 bytes in 24 blocks (ref 0) 0x563205791920 struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057cc010 struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057cc2d0 struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057b0760 struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057cd200 struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057e16c0 struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057f76e0 struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057fa3b0 struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057cc630 struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057b5a00 struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057d1e20 struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057ddd50 struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057d6b30 struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057dc280 struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057e3030 struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057f80d0 struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057e2e80 struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057b4410 struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057c7ad0 struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057cdf10 struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057b0a50 struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057d95e0 struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x563205794760
This is weird, I would expect all SGs connections to be terminated at some point?
Chunk 'struct vlr_subscr'¶
struct vlr_instance contains 315472 bytes in 658 blocks (ref 0) 0x56320577c0d0 struct vlr_subscr contains 1922 bytes in 4 blocks (ref 0) 0x563205837060 struct osmo_fsm_inst contains 266 bytes in 3 blocks (ref 0) 0x563205836b10 SGs-UE(imsi:262420000001131)[0x563205836b10] contains 45 bytes in 1 blocks (ref 0) 0x563205814560 imsi:262420000001131 contains 21 bytes in 1 blocks (ref 0) 0x56320581c120 struct vlr_subscr contains 1922 bytes in 4 blocks (ref 0) 0x563205838a50 struct osmo_fsm_inst contains 266 bytes in 3 blocks (ref 0) 0x563205839130 SGs-UE(imsi:262420000001130)[0x563205839130] contains 45 bytes in 1 blocks (ref 0) 0x563205836f10 imsi:262420000001130 contains 21 bytes in 1 blocks (ref 0) 0x563205803440 struct vlr_subscr contains 1922 bytes in 4 blocks (ref 0) 0x5632058360e0 struct osmo_fsm_inst contains 266 bytes in 3 blocks (ref 0) 0x563205830410 SGs-UE(imsi:262420000001129)[0x563205830410] contains 45 bytes in 1 blocks (ref 0) 0x563205829750 imsi:262420000001129 contains 21 bytes in 1 blocks (ref 0) 0x56320581be90 struct vlr_subscr contains 1922 bytes in 4 blocks (ref 0) 0x563205832900 struct osmo_fsm_inst contains 266 bytes in 3 blocks (ref 0) 0x563205832fe0 SGs-UE(imsi:262420000001128)[0x563205832fe0] contains 45 bytes in 1 blocks (ref 0) 0x563205810490 imsi:262420000001128 contains 21 bytes in 1 blocks (ref 0) 0x5632058318e0 struct vlr_subscr contains 1922 bytes in 4 blocks (ref 0) 0x56320582a920 struct osmo_fsm_inst contains 266 bytes in 3 blocks (ref 0) 0x56320581d030 SGs-UE(imsi:262420000001127)[0x56320581d030] contains 45 bytes in 1 blocks (ref 0) 0x56320581f700 imsi:262420000001127 contains 21 bytes in 1 blocks (ref 0) 0x5632058156e0 ...
This is probably not a problem, the lifetime of a VLR subscriber is controlled by T3212, which is set to 60m by default.
Updated by fixeria over 2 years ago
- % Done changed from 0 to 20
Regarding the 'bssmap: clear command', the problem is in msc_i_ran_enc(). This function calls msc_role_ran_encode(), which allocates the Clear Command message. But unlike the other callers of msc_role_ran_encode(), this function does not free() the message buffer. Here is the fix:
https://gerrit.osmocom.org/c/osmo-msc/+/26460 libmsc: fix memory leak (struct msgb) in msc_i_ran_enc() [NEW]
Updated by neels almost 2 years ago
random notes, hopefully related...
struct sgs_connection contains 152 bytes in 1 blocks (ref 0) 0x5632057cc010
Every VLR subscriber creates an sgs_fsm instance, regardless of whether it is used.
Maybe that factoid is related to the leak? Not sure.
Maybe we can also reduce the memory footprint by only allocating sgs_fsm when
it is needed, possibly unrelated to the struct sgs_connection leak.
IIRC pmaier wrote the SGs code.
struct vlr_subscr contains 1922 bytes in 4 blocks (ref 0) 0x563205837060
This is probably not a problem, the lifetime of a VLR subscriber is controlled by T3212, which is set to 60m by default.
#1974 claims that we keep VLR subscribers as long as there are unused auth
tuples. From a quick look it seems that this claim is not true ... not entirely
sure though.