Actions
Bug #5340
openttcn3-msc-test: more memory leaks
Start date:
12/07/2021
Due date:
% Done:
20%
Resolution:
Spec Reference:
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.
Actions