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.
