Project

General

Profile

Issue #2104

Memory leak in charon

Added by Jeonghoon Lee almost 6 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Category:
libstrongswan
Affected version:
5.1.2
Resolution:
No change required

Description

Hi,

I can see that memory leak occurs whenever logs are printed or NAT packet is transmitted in charon.
I tried to block all logs in strongswan and some memory leak that occurred every second was disappeared, however memory leak in NAT transmission is still happened, as followings.
Can you please let me know patch information for the both memory leak issue?

NAT time is 20secs. VmData is increasing every 20secs.

===================== Iteration 23 ========================= 
Wed Sep  7 09:26:20 UTC 2016
Name:    charon
State:    S (sleeping)
Tgid:    8396
Pid:    8396
PPid:    8395
TracerPid:    0
Uid:    0    0    0    0
Gid:    0    0    0    0
FDSize:    32
Groups:    1000 1001 1007 3003 3005 
VmPeak:       77428 kB
VmSize:       77428 kB
VmLck:           0 kB
VmPin:           0 kB
VmHWM:        2380 kB
VmRSS:        2380 kB
VmData:       72968 kB
VmStk:         136 kB
VmExe:          16 kB
VmLib:        3704 kB
VmPTE:          80 kB
VmSwap:           0 kB
Threads:    20
SigQ:    2/11045
SigPnd:    0000000000000000
ShdPnd:    0000000000000000
SigBlk:    0000000000000000
SigIgn:    0000000000001000
SigCgt:    0000000000008cf8
CapInh:    0000000800003000
CapPrm:    0000000800003000
CapEff:    0000000800003000
CapBnd:    0000001fffffffff
Seccomp:    0
Cpus_allowed:    f
Cpus_allowed_list:    0-3
voluntary_ctxt_switches:    37
nonvoluntary_ctxt_switches:    31

===================== Iteration 50 ========================= 
Wed Sep  7 09:26:41 UTC 2016
Name:    charon
State:    S (sleeping)
Tgid:    8396
Pid:    8396
PPid:    8395
TracerPid:    0
Uid:    0    0    0    0
Gid:    0    0    0    0
FDSize:    32
Groups:    1000 1001 1007 3003 3005 
VmPeak:       83560 kB
VmSize:       83560 kB
VmLck:           0 kB
VmPin:           0 kB
VmHWM:        2380 kB
VmRSS:        2380 kB
VmData:       79100 kB
VmStk:         136 kB
VmExe:          16 kB
VmLib:        3704 kB
VmPTE:          86 kB
VmSwap:           0 kB
Threads:    21
SigQ:    2/11045
SigPnd:    0000000000000000
ShdPnd:    0000000000000000
SigBlk:    0000000000000000
SigIgn:    0000000000001000
SigCgt:    0000000000008cf8
CapInh:    0000000800003000
CapPrm:    0000000800003000
CapEff:    0000000800003000
CapBnd:    0000001fffffffff
Seccomp:    0
Cpus_allowed:    f
Cpus_allowed_list:    0-3
voluntary_ctxt_switches:    37
nonvoluntary_ctxt_switches:    31

===================== Iteration 72 ========================= 
Wed Sep  7 09:27:01 UTC 2016
Name:    charon
State:    S (sleeping)
Tgid:    8396
Pid:    8396
PPid:    8395
TracerPid:    0
Uid:    0    0    0    0
Gid:    0    0    0    0
FDSize:    32
Groups:    1000 1001 1007 3003 3005 
VmPeak:       87640 kB
VmSize:       87640 kB
VmLck:           0 kB
VmPin:           0 kB
VmHWM:        2380 kB
VmRSS:        2380 kB
VmData:       83180 kB
VmStk:         136 kB
VmExe:          16 kB
VmLib:        3704 kB
VmPTE:          90 kB
VmSwap:           0 kB
Threads:    21
SigQ:    2/11045
SigPnd:    0000000000000000
ShdPnd:    0000000000000000
SigBlk:    0000000000000000
SigIgn:    0000000000001000
SigCgt:    0000000000008cf8
CapInh:    0000000800003000
CapPrm:    0000000800003000
CapEff:    0000000800003000
CapBnd:    0000001fffffffff
Seccomp:    0
Cpus_allowed:    f
Cpus_allowed_list:    0-3
voluntary_ctxt_switches:    37
nonvoluntary_ctxt_switches:    31

Thank you.

History

#1 Updated by Tobias Brunner almost 6 years ago

  • Description updated (diff)
  • Status changed from New to Feedback
  • Priority changed from High to Normal

What increases is VmSize (virtual memory), VmData (data segment), VmPTE (page table entries), and VmRSS (the actual resident memory) does not increase. That the virtual memory increases is pretty normal when allocations are made and freed again (the allocator keeps the freed memory around for future allocations). So I don't think there is an actual memory leak.

#2 Updated by Jeonghoon Lee almost 6 years ago

Procrank shows that PSS was increased from 60,891K to 71,027K after 30mins with sending DPD every 1sec.
After charon restart, PSS is quite smaller than before from 71,027K to 3,685K.

1. Procrank
  PID       Vss      Rss      Pss      Uss  cmdline
2386  2024280K  217400K  156521K  146860K  com.android.systemui
1709  2531704K  204596K  129342K  118304K  system_server
3437  2002064K  161676K  102703K   94052K  com.lge.launcher3
3078  1935724K  143420K   71109K   61668K  com.google.android.gms.persistent
3306  1278340K  122216K   67739K   60808K  com.lge.signboard
3346  2419624K  127288K   63247K   58012K  com.google.android.googlequicksearchbox:search
8398  14609468K   62056K   60891K   60852K  /system/bin/charon

2. Procrank
  PID       Vss      Rss      Pss      Uss  cmdline
2386  2024280K  218400K  157465K  147860K  com.android.systemui
1709  2526344K  205156K  129739K  118832K  system_server
3437  2002064K  161676K  102635K   94052K  com.lge.launcher3
8398  17173836K   72192K   71027K   70988K  /system/bin/charon
3306  1278340K  123104K   67850K   60408K  com.lge.signboard
3346  2419624K  127288K   63165K   58008K  com.google.android.googlequicksearchbox:search

3. Procrank
  PID       Vss      Rss      Pss      Uss  cmdline
2386  1998504K  224244K  162505K  153392K  com.android.systemui
1709  2541352K  208812K  134265K  122516K  system_server
3437  2004356K  164528K  104783K   96816K  com.lge.launcher3
3306  1283740K  128280K   71935K   64784K  com.lge.signboard
3346  2434176K  132384K   67984K   62864K  com.google.android.googlequicksearchbox:search
28987   156976K    4836K    3685K    3648K  /system/bin/charon

#3 Updated by Tobias Brunner almost 6 years ago

Procrank shows that PSS was increased from 60,891K to 71,027K after 30mins with sending DPD every 1sec.
After charon restart, PSS is quite smaller than before from 71,027K to 3,685K.

PSS is the Proportional Set Size which is the amount of memory shared with other processes (e.g. via shared libraries) divided by the number of processes sharing it. USS is probably more interesting as that indicates memory that's private to the process (see e.g. http://www.2net.co.uk/tutorial/procrank).

#4 Updated by Jeonghoon Lee almost 6 years ago

Thank you for your feedback. we're considering below code to resolve the memory issue. What do you think of this code? Is there any side effect?

// shceduler.c
void alarmsleep(private_scheduler_t * this) {
this->condvar->broadcast(this->condvar);
pthread_detach(pthread_self()); // add
}

#5 Updated by Tobias Brunner almost 6 years ago

we're considering below code to resolve the memory issue. What do you think of this code? Is there any side effect?

I don't see what the point of that would be.

#6 Updated by Tobias Brunner over 5 years ago

  • Category set to libstrongswan
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to No change required

Also available in: Atom PDF