Project

General

Profile

Actions

Bug #5340

open

ttcn3-msc-test: more memory leaks

Added by fixeria about 2 years ago. Updated almost 2 years ago.

Status:
New
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
12/07/2021
Due date:
% Done:

20%

Resolution:
Spec Reference:

Description

We have talloc reports in the build artifacts starting from today:

https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test/1490/artifact/logs/msc-tester/*.talloc

And here one can clearly see leaked memory (MSC_Tests_Iu.TC_mo_cc_iu_release executed last):

https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test/1490/artifact/logs/msc-tester/MSC_Tests_Iu.TC_mo_cc_iu_release.talloc/*view*/

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 #1

Updated by fixeria about 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]

Actions #2

Updated by laforge almost 2 years ago

  • Assignee set to fixeria
Actions #3

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.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)