Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Very huge memory consumtion of bgpd after several 100 sh commands #5445

Closed
crami opened this issue Dec 1, 2019 · 1 comment · Fixed by #5446
Closed

Very huge memory consumtion of bgpd after several 100 sh commands #5445

crami opened this issue Dec 1, 2019 · 1 comment · Fixed by #5446
Labels
bgp bug

Comments

@crami
Copy link

crami commented Dec 1, 2019 •
edited
Loading

I've written a script to collect metrics via vtysh for Prometheus. Script is available here: https://git.freestone.net/cramer/frr-prometheus-stats

After running some hours memory of bgpd increased to > 30GB
I run two fill feeds and several peerings.

Config

frr version 7.2
frr defaults traditional
hostname bluepill
log syslog informational
agentx
log commands
rpki
  rpki polling_period 300
  rpki cache 127.0.0.1 3323 preference 1
  exit
service integrated-vtysh-config
!
debug rpki
!
ip route 10.9.0.0/24 193.5.69.19
ip route 10.9.1.0/24 193.5.69.19
ip route 192.168.68.0/24 193.5.69.19
ip route 193.5.68.0/23 Null0
ip route 193.5.69.8/31 193.5.69.19
ipv6 route 2001:67c:8::/48 Null0
ipv6 route 2001:67c:8:abc0::/60 2001:67c:8:fefe:1::1
ipv6 route 2001:67c:8:ff1::/64 2001:67c:8:1::13
ipv6 route 2001:67c:8:ff2::/64 2001:67c:8:1::13
!
interface br1
 ip address 193.5.69.17/28
 ipv6 address 2001:67c:8:1::1/64
!
interface dummy0
 description Loopback
 ip address 193.5.69.1/32
 ipv6 address 2001:67c:8:ffff:ffff::1/128
!
interface eth0.50
 ip address 193.5.69.5/30
!
interface eth0.51
 ip address 83.150.1.207/31
 ipv6 address 2001:8e0:ffff:1::1d2/124
!
interface eth1
 ip address 212.103.68.174/30
 ipv6 address 2a00:c38::1:0:152/124
!
interface eth2
 ip address 91.206.52.103/23
 ipv6 address 2001:7f8:24::67/64
!
router bgp 196621
 bgp router-id 193.5.69.1
 bgp log-neighbor-changes
 neighbor PG4-SwissIX peer-group
 neighbor PG4-SwissIX-RS peer-group
 neighbor PG6-SwissIX peer-group
 neighbor PG6-SwissIX-RS peer-group
 neighbor PG6-SwissIX-RS remote-as 42476
 neighbor 91.206.52.24 remote-as 3856
 neighbor 91.206.52.24 peer-group PG4-SwissIX
 neighbor 91.206.52.32 remote-as 21232
 neighbor 91.206.52.32 peer-group PG4-SwissIX
 neighbor 91.206.52.66 remote-as 20893
 neighbor 91.206.52.66 peer-group PG4-SwissIX
 neighbor 91.206.52.77 remote-as 12350
 neighbor 91.206.52.77 peer-group PG4-SwissIX
 neighbor 91.206.52.100 remote-as 21232
 neighbor 91.206.52.100 peer-group PG4-SwissIX
 neighbor 91.206.52.101 remote-as 57118
 neighbor 91.206.52.101 peer-group PG4-SwissIX
 neighbor 91.206.52.101 description CommunityRack.ch
 neighbor 91.206.52.143 remote-as 9002
 neighbor 91.206.52.143 peer-group PG4-SwissIX
 neighbor 91.206.52.191 remote-as 33891
 neighbor 91.206.52.191 peer-group PG4-SwissIX
 neighbor 2001:7f8:24::5 remote-as 42473
 neighbor 2001:7f8:24::5 peer-group PG6-SwissIX
 neighbor 2001:7f8:24::18 remote-as 3856
 neighbor 2001:7f8:24::18 peer-group PG6-SwissIX
 neighbor 2001:7f8:24::5b remote-as 41913
 neighbor 2001:7f8:24::5b peer-group PG6-SwissIX
 neighbor 2001:7f8:24::bf remote-as 33891
 neighbor 2001:7f8:24::bf peer-group PG6-SwissIX
 neighbor 2001:7f8:24::d2 remote-as 61287
 neighbor 2001:7f8:24::d2 peer-group PG6-SwissIX
 neighbor 2001:7f8:24::fb peer-group PG6-SwissIX-RS
 neighbor 2001:7f8:24::fc peer-group PG6-SwissIX-RS
 neighbor 83.150.1.206 remote-as 8758
 neighbor 83.150.1.206 description iway Transit
 neighbor 83.150.63.23 remote-as 65533
 neighbor 83.150.63.23 description bgpws.freestone.net
 neighbor 83.150.63.23 passive
 neighbor 83.150.63.23 ebgp-multihop 10
 neighbor 91.206.52.251 remote-as 42476
 neighbor 91.206.52.252 remote-as 42476
 neighbor 91.206.52.253 remote-as 12654
 neighbor 91.206.52.253 description RIPE RRC20
 neighbor 193.5.69.6 remote-as 65501
 neighbor 212.103.68.173 remote-as 15576
 neighbor 212.103.68.173 password idunefiv64
 neighbor 2001:7f8:24::65 remote-as 57118
 neighbor 2001:7f8:24::fd remote-as 12654
 neighbor 2001:7f8:24::fd description RIPE RIS Collector rrc20
 neighbor 2001:8e0:40:315::1:1 remote-as 65533
 neighbor 2001:8e0:40:315::1:1 ebgp-multihop 10
 neighbor 2001:8e0:ffff:1::1d1 remote-as 8758
 neighbor 2a00:c38::1:0:151 remote-as 15576
 neighbor 2a00:c38::1:0:151 password idunefiv64
 !
 address-family ipv4 unicast
  network 193.5.68.0/23 route-map RM4-Originate
  neighbor PG4-SwissIX route-map RM4-SwissIX-IN in
  neighbor PG4-SwissIX route-map RM4-SwissIX-OUT out
  no neighbor PG6-SwissIX activate
  neighbor 91.206.52.24 maximum-prefix 600
  neighbor 91.206.52.32 maximum-prefix 100
  neighbor 91.206.52.66 maximum-prefix 1
  neighbor 91.206.52.77 maximum-prefix 40
  neighbor 91.206.52.100 maximum-prefix 100
  neighbor 91.206.52.101 soft-reconfiguration inbound
  neighbor 91.206.52.101 maximum-prefix 10
  neighbor 91.206.52.101 prefix-list PL4-AS57118 in
  neighbor 91.206.52.101 route-map RM4-Customer-IN in
  neighbor 91.206.52.101 route-map RM4-Customer-OUT out
  neighbor 91.206.52.143 maximum-prefix 40000
  neighbor 91.206.52.191 maximum-prefix 20000
  no neighbor 2001:7f8:24::fb activate
  no neighbor 2001:7f8:24::fc activate
  neighbor 83.150.1.206 soft-reconfiguration inbound
  neighbor 83.150.1.206 route-map RM4-iway-IN in
  neighbor 83.150.1.206 route-map RM4-iway-OUT out
  neighbor 83.150.63.23 prefix-list PL4-None in
  neighbor 91.206.52.251 maximum-prefix 100000
  neighbor 91.206.52.251 route-map RM4-SwissIX-RS-IN in
  neighbor 91.206.52.251 route-map RM4-SwissIX-RS-OUT out
  neighbor 91.206.52.252 maximum-prefix 100000
  neighbor 91.206.52.252 route-map RM4-SwissIX-RS-IN in
  neighbor 91.206.52.252 route-map RM4-SwissIX-RS-OUT out
  neighbor 91.206.52.253 maximum-prefix 20
  neighbor 91.206.52.253 prefix-list PL4-DenyDefault out
  neighbor 91.206.52.253 route-map RM4-SwissIX-IN in
  neighbor 193.5.69.6 default-originate
  neighbor 193.5.69.6 route-map RM4-DefaultOnly out
  neighbor 212.103.68.173 route-map RM4-NTS-IN in
  neighbor 212.103.68.173 route-map RM4-NTS-OUT out
  no neighbor 2001:7f8:24::65 activate
  no neighbor 2001:7f8:24::fd activate
  no neighbor 2001:8e0:40:315::1:1 activate
  no neighbor 2001:8e0:ffff:1::1d1 activate
  no neighbor 2a00:c38::1:0:151 activate
  maximum-paths 4
 exit-address-family
 !
 address-family ipv6 unicast
  network 2001:67c:8::/48 route-map RM6-Originate
  neighbor PG6-SwissIX route-map RM6-SwissIX-IN in
  neighbor PG6-SwissIX route-map RM6-SwissIX-OUT out
  neighbor PG6-SwissIX-RS maximum-prefix 40000
  neighbor PG6-SwissIX-RS route-map RM6-SwissIX-RS-IN in
  neighbor PG6-SwissIX-RS route-map RM6-SwissIX-RS-OUT out
  neighbor 2001:7f8:24::5 activate
  neighbor 2001:7f8:24::5 maximum-prefix 500
  neighbor 2001:7f8:24::18 activate
  neighbor 2001:7f8:24::18 maximum-prefix 600
  neighbor 2001:7f8:24::5b activate
  neighbor 2001:7f8:24::5b maximum-prefix 50
  neighbor 2001:7f8:24::bf activate
  neighbor 2001:7f8:24::bf maximum-prefix 2000
  neighbor 2001:7f8:24::d2 activate
  neighbor 2001:7f8:24::d2 maximum-prefix 10
  neighbor 2001:7f8:24::fb activate
  neighbor 2001:7f8:24::fc activate
  neighbor 2001:7f8:24::65 activate
  neighbor 2001:7f8:24::65 soft-reconfiguration inbound
  neighbor 2001:7f8:24::65 prefix-list PL6-AS57118 in
  neighbor 2001:7f8:24::65 route-map RM6-Customer-IN in
  neighbor 2001:7f8:24::65 route-map RM6-Customer-OUT out
  neighbor 2001:7f8:24::fd activate
  neighbor 2001:7f8:24::fd prefix-list PL6-DenyDefault out
  neighbor 2001:7f8:24::fd route-map RM6-SwissIX-IN in
  neighbor 2001:8e0:40:315::1:1 activate
  neighbor 2001:8e0:40:315::1:1 prefix-list PL4-DenyAll in
  neighbor 2001:8e0:ffff:1::1d1 activate
  neighbor 2001:8e0:ffff:1::1d1 route-map RM6-iway-IN in
  neighbor 2001:8e0:ffff:1::1d1 route-map RM6-iway-OUT out
  neighbor 2a00:c38::1:0:151 activate
  neighbor 2a00:c38::1:0:151 route-map RM6-NTS-IN in
  neighbor 2a00:c38::1:0:151 route-map RM6-NTS-OUT out
 exit-address-family
!
ip prefix-list PL4-AS57118 seq 10 permit 91.233.182.0/24
ip prefix-list PL4-AS57118 seq 15 permit 185.95.216.0/23 le 24
ip prefix-list PL4-AS57118 seq 20 permit 185.95.218.0/24
ip prefix-list PL4-AS57118 seq 25 permit 185.95.219.0/24
ip prefix-list PL4-AS57118 seq 30 permit 185.104.19.0/24
ip prefix-list PL4-AS57118 seq 35 permit 185.117.12.0/24
ip prefix-list PL4-AS57118 seq 40 permit 185.117.13.0/24
ip prefix-list PL4-AS57118 seq 45 permit 185.117.14.0/24
ip prefix-list PL4-AS57118 seq 5 permit 91.199.218.0/24
ip prefix-list PL4-AS57118 seq 50 permit 185.119.104.0/22 le 24
ip prefix-list PL4-AS57118 seq 55 permit 193.36.104.0/22 le 24
ip prefix-list PL4-AS57118 seq 60 permit 195.170.160.0/24
ip prefix-list PL4-DefaultRoute seq 5 permit 0.0.0.0/0
ip prefix-list PL4-DenyAll seq 5 permit 0.0.0.0/0 le 32
ip prefix-list PL4-DenyDefault seq 10 permit 0.0.0.0/0 ge 1 le 24
ip prefix-list PL4-DenyDefault seq 5 deny 0.0.0.0/0
ip prefix-list PL4-None seq 5 deny 0.0.0.0/0 le 32
ip prefix-list PL4-OwnPrefixes seq 5 permit 193.5.68.0/23
!
ipv6 prefix-list PL6-AS57118 seq 10 permit 2001:67c:458::/48
ipv6 prefix-list PL6-AS57118 seq 15 permit 2001:67c:47c::/48
ipv6 prefix-list PL6-AS57118 seq 20 permit 2001:67c:71c::/48
ipv6 prefix-list PL6-AS57118 seq 25 permit 2001:67c:2614::/48
ipv6 prefix-list PL6-AS57118 seq 30 permit 2001:67c:2c28::/48
ipv6 prefix-list PL6-AS57118 seq 35 permit 2001:67c:2d70::/48
ipv6 prefix-list PL6-AS57118 seq 40 permit 2a00:f740:400::/48
ipv6 prefix-list PL6-AS57118 seq 45 permit 2a05:fc80::/29 le 48
ipv6 prefix-list PL6-AS57118 seq 5 permit 2001:678:918::/48
ipv6 prefix-list PL6-AS57118 seq 50 permit 2a06:8280::/32 le 48
ipv6 prefix-list PL6-AS57118 seq 55 permit 2a06:8281::/32 le 48
ipv6 prefix-list PL6-AS57118 seq 60 permit 2a06:8a00::/29 le 48
ipv6 prefix-list PL6-AS57118 seq 65 permit 2a0d:d740::/29 le 48
ipv6 prefix-list PL6-DefaultRoute seq 5 permit ::/0
ipv6 prefix-list PL6-DenyDefault seq 10 permit ::/0 ge 1 le 48
ipv6 prefix-list PL6-DenyDefault seq 5 deny ::/0
ipv6 prefix-list PL6-None seq 5 deny ::/0 le 128
ipv6 prefix-list PL6-OwnPrefixes seq 5 permit 2001:67c:8::/48
!
bgp as-path access-list AS-Avoid-SwissIX-RS permit 15576$
bgp as-path access-list AS-Avoid-SwissIX-RS permit 8758$
bgp as-path access-list AS-Tier1-List permit _(174|209|286|701|1239|1299|2828|2914|3257|3320|3356|3549|5511|6453|6461|6762|7018|12956)_
!
bgp large-community-list standard LCL-AllInternalCommunities permit 196621:3:1
bgp large-community-list standard LCL-AllInternalCommunities permit 196621:3:2
bgp large-community-list standard LCL-AllInternalCommunities permit 196621:3:3
bgp large-community-list standard LCL-AllInternalCommunities permit 196621:3:4
bgp large-community-list standard LCL-AllInternalCommunities permit 196621:3:5
bgp large-community-list standard LCL-AllInternalCommunities permit 196621:4:1
bgp large-community-list standard LCL-AllInternalCommunities permit 196621:4:2
bgp large-community-list standard LCL-AllInternalCommunities permit 196621:4:3
bgp large-community-list standard LCL-Customers permit 196621:3:4
bgp large-community-list standard LCL-OwnPrefix permit 196621:3:1
bgp large-community-list standard LCL-Peers permit 196621:3:2
bgp large-community-list standard LCL-RPKI-Invalid permit 196621:4:2
bgp large-community-list standard LCL-RPKI-Unknown permit 196621:4:3
bgp large-community-list standard LCL-RPKI-Valid permit 196621:4:1
bgp large-community-list standard LCL-RouteServer permit 196621:3:3
bgp large-community-list standard LCL-Transit permit 196621:3:5
!
route-map RM-BGPtoZebra deny 10
 match tag 666666
!
route-map RM-BGPtoZebra permit 10000
!
route-map RM-RPKI-Deny-Invalid deny 10
 match large-community LCL-RPKI-Invalid
!
route-map RM-RPKI-IN permit 10
 match rpki valid
 set large-community 196621:4:1 additive
!
route-map RM-RPKI-IN permit 20
 match rpki invalid
 set community no-export additive
 set large-community 196621:4:2 additive
 set tag 666666
!
route-map RM-RPKI-IN permit 30
 match rpki notfound
 set large-community 196621:4:3 additive
!
route-map RM-RPKI-IN permit 40
!
route-map RM4-Customer-IN deny 5
 match as-path AS-Tier1-List
!
route-map RM4-Customer-IN permit 10
 call RM-RPKI-IN
 on-match next
 set large-community 196621:3:4 additive
 set local-preference 6000
!
route-map RM4-Customer-IN permit 20
 match large-community LCL-RPKI-Invalid
 set local-preference 1
 set metric 10000
!
route-map RM4-Customer-OUT permit 10
 match large-community LCL-OwnPrefix
!
route-map RM4-Customer-OUT permit 20
 match large-community LCL-Peers
!
route-map RM4-Customer-OUT permit 30
 match large-community LCL-Customers
!
route-map RM4-Customer-OUT permit 40
 match large-community LCL-Transit
!
route-map RM4-DefaultOnly permit 10
 match ip address prefix-list PL4-DefaultRoute
!
route-map RM4-NTS-IN deny 5
 match ip address prefix-list PL4-DefaultRoute
!
route-map RM4-NTS-IN permit 10
 call RM-RPKI-IN
 set large-community 196621:3:5 additive
 set local-preference 200
!
route-map RM4-NTS-OUT permit 10
 match large-community LCL-OwnPrefix
 set metric 10
!
route-map RM4-NTS-OUT permit 20
 match large-community LCL-Customers
!
route-map RM4-Originate permit 10
 set large-community 196621:3:1 additive
!
route-map RM4-SwissI-OUT deny 65000
!
route-map RM4-SwissIX-IN permit 10
 call RM-RPKI-IN
 set large-community 196621:3:2 additive
 set local-preference 3000
!
route-map RM4-SwissIX-OUT permit 10
 match large-community LCL-OwnPrefix
 set metric 5
!
route-map RM4-SwissIX-OUT permit 20
 match large-community LCL-Customers
!
route-map RM4-SwissIX-RS-IN permit 10
 call RM-RPKI-IN
 on-match next
 set large-community 196621:3:3 additive
!
route-map RM4-SwissIX-RS-IN permit 1000
 set local-preference 2950
!
route-map RM4-SwissIX-RS-IN permit 20
 match as-path AS-Avoid-SwissIX-RS
 set local-preference 50
!
route-map RM4-SwissIX-RS-OUT deny 65000
!
route-map RM4-SwissIX-RS-OUT permit 10
 match large-community LCL-OwnPrefix
!
route-map RM4-SwissIX-RS-OUT permit 20
 match large-community LCL-Customers
!
route-map RM4-iway-IN deny 5
 match ip address prefix-list PL4-DefaultRoute
!
route-map RM4-iway-IN permit 10
 call RM-RPKI-IN
 set large-community 196621:3:5 additive
 set local-preference 200
!
route-map RM4-iway-OUT permit 10
 match large-community LCL-OwnPrefix
 set metric 10
!
route-map RM4-iway-OUT permit 20
 match large-community LCL-Customers
!
route-map RM6-Customer-IN deny 5
 match as-path AS-Tier1-List
!
route-map RM6-Customer-IN permit 10
 on-match next
 set large-community 196621:3:4 additive
 set local-preference 6000
!
route-map RM6-Customer-IN permit 20
 match large-community LCL-RPKI-Invalid
 set local-preference 1
 set metric 10000
!
route-map RM6-Customer-OUT permit 10
 match large-community LCL-OwnPrefix
!
route-map RM6-Customer-OUT permit 20
 match large-community LCL-Peers
!
route-map RM6-Customer-OUT permit 30
 match large-community LCL-Customers
!
route-map RM6-Customer-OUT permit 40
 match large-community LCL-Transit
!
route-map RM6-DefaultOnly permit 10
 match ip address prefix-list PL6-DefaultRoute
!
route-map RM6-NTS-IN deny 5
 match ipv6 address prefix-list PL6-DefaultRoute
!
route-map RM6-NTS-IN permit 10
 call RM-RPKI-IN
 set large-community 196621:3:5 additive
 set local-preference 200
!
route-map RM6-NTS-OUT permit 10
 match large-community LCL-OwnPrefix
 set metric 10
!
route-map RM6-NTS-OUT permit 20
 match large-community LCL-Customers
!
route-map RM6-Originate permit 10
 set large-community 196621:3:1 additive
!
route-map RM6-SwissIX-IN permit 10
 call RM-RPKI-IN
 set large-community 196621:3:2 additive
 set local-preference 3000
!
route-map RM6-SwissIX-OUT permit 10
 match large-community LCL-OwnPrefix
 set metric 5
!
route-map RM6-SwissIX-OUT permit 20
 match large-community LCL-Customers
!
route-map RM6-SwissIX-RS-IN permit 10
 call RM-RPKI-IN
 on-match next
 set large-community 196621:3:3 additive
!
route-map RM6-SwissIX-RS-IN permit 1000
 set local-preference 2950
!
route-map RM6-SwissIX-RS-IN permit 20
 match as-path AS-Avoid-SwissIX-RS
 set local-preference 50
!
route-map RM6-SwissIX-RS-OUT permit 10
 match large-community LCL-OwnPrefix
!
route-map RM6-SwissIX-RS-OUT permit 20
 match large-community LCL-Customers
!
route-map RM6-iway-IN deny 5
 match ipv6 address prefix-list PL6-DefaultRoute
!
route-map RM6-iway-IN permit 10
 call RM-RPKI-IN
 set large-community 6196621:3:5 additive
 set local-preference 200
!
route-map RM6-iway-OUT permit 10
 match large-community LCL-OwnPrefix
 set metric 10
!
route-map RM6-iway-OUT permit 20
 match large-community LCL-Customers
!
ip protocol bgp route-map RM-BGPtoZebra
!
line vty

sh memory

bluepill# sh memory 
Memory statistics for zebra:
System allocator statistics:
  Total heap allocated:  470 MiB
  Holding block headers: 18 MiB
  Used small blocks:     0 bytes
  Used ordinary blocks:  460 MiB
  Free small blocks:     6672 bytes
  Free ordinary blocks:  9698 KiB
  Ordinary blocks:       166540
  Small blocks:          112
  Holding blocks:        2
(see system documentation for 'mallinfo' for meaning)
--- qmem libfrr ---
Type                          : Current#   Size       Total     Max#  MaxBytes
Buffer                        :        7     24         184        7       184
Buffer data                   :        1   4120        4120        3     12360
Host config                   :        2 variable        48        2        48
Command Tokens                :     3846     72      277008     3856    277744
Command Token Text            :     2810 variable     92992     2819     93296
Command Token Help            :     2810 variable     67488     2819     67704
Command Argument              :        2 variable        48       12       288
Command Argument Name         :      884 variable     21392      890     21536
RCU thread                    :        6 variable       736        6       736
FRR POSIX Thread              :        8 variable       640        8       640
POSIX sync primitives         :        8 variable       400        8       400
Graph                         :       26      8         624       27       648
Graph Node                    :     4500     32      180320     4502    180400
Hash                          :      652 variable     31504      652     31504
Hash Bucket                   :      883     32       35352      884     35408
Hash Index                    :      326 variable     97904      326     97904
Hook entry                    :       18     48        1024       18      1024
Interface                     :       18    264        4752       18      4752
Connected                     :       22     48        1232       22      1232
Link List                     :      226     40        9568      243     10504
Link Node                     :      449     24       10920    19367    465112
Logging                       :        1     72          72        1        72
Module loading name           :        1      5          24        1        24
Nexthop                       :   865004    112   103800512   866197 103943688
NetNS Context                 :        2 variable       128        2       128
NetNS Name                    :        1     18          24        1        24
Northbound Node               :        5    392        1992        5      1992
Northbound Configuration      :        2     72         144        3       216
Northbound Configuration Entry:        6    264        1584        6      1584
Prefix List                   :       11     80         968       11       968
Prefix List Str               :       11 variable       264       11       264
Prefix List Entry             :       36    112        4352       36      4352
Prefix List Trie Table        :       32   4096      131328       32    131328
Prefix                        :       22     48        1248       22      1248
Privilege information         :        4 variable       160        4       160
Route map                     :       28    104        2912       28      2912
Route map index               :       59    136        8088       59      8088
Route map rule str            :        7 variable       168        7       168
Route map dependency          :        3     24          72        3        72
Route map dependency data     :       15     16         360       15       360
Stream                        :        6 variable    166800     4822    823816
Stream FIFO                   :        6     64         432        8       592
Route table                   :       29     56        1624       29      1624
Route node                    :  1586110 variable 190333344  1586636 190396464
Thread                        :       34    168        5728       40      6736
Thread master                 :       19 variable     83656       19     83656
Thread Poll Info              :       10   8192       82000       10     82000
Thread stats                  :       26     72        1872       27      1944
Typed-hash bucket             :       15 variable  18885560       15  18886088
Typed-heap array              :        1    576         584        1       584
Vector                        :     9059     16      217832     9062    217904
Vector index                  :     9059 variable    297704     9062    297912
VRF                           :        1    200         200        1       200
VRF bit-map                   :        2      8          48        2        48
VTY                           :        4 variable     19744        4     19744
Work queue name string        :        1     22          24        1        24
YANG module                   :        1     48          56        1        56
--- qmem Label Manager ---
Type                          : Current#   Size       Total     Max#  MaxBytes
--- qmem zebra ---
Type                          : Current#   Size       Total     Max#  MaxBytes
Zebra Interface Information   :       18    344        6192       18      6192
Route Entry                   :   865002     88    76120400   866194  76225296
RIB destination               :   864932     88    76114128   865215  76139032
Zebra DPlane Provider         :        1    232         232        1       232
Zebra Name Space              :        5 variable       552        5       552
RIB table info                :        4     16          96        4        96
Nexthop tracking object       :       55    232       13160       62     14896
ZEBRA VRF                     :        1   4616        4616        1      4616
--- qmem Table Manager ---
Type                          : Current#   Size       Total     Max#  MaxBytes

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  > 2GB
  Holding block headers: 24 MiB
  Used small blocks:     0 bytes
  Used ordinary blocks:  > 2GB
  Free small blocks:     14 KiB
  Free ordinary blocks:  108 MiB
  Ordinary blocks:       27102
  Small blocks:          191
  Holding blocks:        2
(see system documentation for 'mallinfo' for meaning)
--- qmem libfrr ---
Type                          : Current#   Size       Total     Max#  MaxBytes
Buffer                        :        6     24         144        6       176
Buffer data                   :        1 variable      4120    27648 113909840
Host config                   :        2 variable        48        2        48
Command Tokens                :    10661     72      768264    10671    769000
Command Token Text            :     7840 variable    270032     7850    270560
Command Token Help            :     7840 variable    188784     7850    189024
Command Argument              :        2 variable        48       12       288
Command Argument Name         :     1698 variable     40896     1708     41136
RCU thread                    :        2    128         272        2       272
FRR POSIX Thread              :        4 variable       320        4       320
POSIX sync primitives         :        4 variable       192        4       192
Graph                         :       39      8         936       40       960
Graph Node                    :    12685     32      508984    12687    509064
Hash                          :      587 variable     28280      587     28280
Hash Bucket                   :   878350     32    35167248   995127  39838504
Hash Index                    :      294 variable  13555864      295  17754248
Hook entry                    :        8     48         448        8       448
Interface                     :       18    264        4752       18      4752
Connected                     :       22     48        1232       22      1232
Link List                     :      104     40        4208      113      4584
Link Node                     :      424     24       10272      564     15904
Logging                       :        1     72          72        1        72
Module loading name           :        2      5          48        2        48
Nexthop                       :       52    112        6304       59      7176
Northbound Configuration      :        2     72         144        2       144
Prefix List                   :       11     80         968       11       968
Prefix List Str               :       11 variable       264       11       264
Prefix List Entry             :       36    112        4320       36      4320
Prefix List Trie Table        :       32   4096      131328       32    131328
Prefix                        :       22     48        1248       23      1304
Privilege information         :        3 variable       136        3       136
Ring buffer                   :       64 variable   1312272       68   1394288
Route map                     :       28    104        2912       28      2912
Route map index               :       59    136        8024       59      8024
Route map rule str            :       80 variable      1920       80      1920
Route map dependency          :       10     24         240       10       240
Route map dependency data     :       46     16        1104       46      1104
Skip List                     :        2     56         128        2       128
Skip Node                     :        4    160         672        4       672
Socket union                  :       50     28        2032       52      2112
Stream                        :      100 variable    556544   159835  29931944
Stream FIFO                   :       64     64        4896       68      5184
Route table                   :      106     56        5968      106      5968
Thread                        :       83    168       13960      119     20008
Thread master                 :       11 variable     50184       11     50184
Thread Poll Info              :        6   8192       49200        6     49200
Thread stats                  :       29     72        2088       29      2088
Typed-hash bucket             :        9 variable  18881888        9  18882400
Typed-heap array              :        1    576         584        1       584
Vector                        :    25455     16      612008    25459    612104
Vector index                  :    25455 variable    823480    25459    823720
VRF                           :        1    200         200        1       200
VRF bit-map                   :        3      8          72        3        72
VTY                           :        4 variable     19760        4     19760
Work queue                    :        3    152         456        4       608
Work queue name string        :        3 variable        72        4        96
Zclient                       :        2   3216        6448        2      6448
Redistribution instance IDs   :        6      2         144        6       144
--- qmem bgpd ---
Type                          : Current#   Size       Total     Max#  MaxBytes
Mac Hash Entry                :       13     16         312       14       336
Mac Hash Entry Interface String:       18 variable       432       19       456
BGP instance                  :        2 variable      5856        2      5856
BGP listen socket details     :        2     48         112        2       112
BGP peer                      :       47  20920      983240       48   1004160
BGP peer hostname             :       50 variable      1200       52      1248
Peer group                    :        4     64         288        4       288
BGP Peer group hostname       :        4 variable        96        4        96
Peer description              :        5 variable       136        5       136
Peer password string          :        2     11          48        2        48
BGP peer af                   :       27     80        2424       29      2600
BGP update group              :       15    104        1560       15      1560
BGP update subgroup           :       15    240        3720       15      3720
BGP packet                    :       15     56         840       16       992
BGP attribute                 :   604909    232   140371288   612096 142018944
BGP aspath                    :   241703     40     9668856   241735   9670136
BGP aspath seg                :   242141     24     5812024   242173   5812824
BGP aspath segment data       :   242141 variable   6513576   242174   6514608
BGP aspath str                :   241705 variable  16335176   241737  16338184
BGP table                     :       93     40        3720       93      3720
BGP node                      :  1586028    184   291869168  1586554 291964528
BGP route                     :  1730959    112   207777992  1731170 207803376
BGP connected                 :       12      4         288       12       288
BGP static                    :        2    136         288        2       288
BGP synchronise               :      687     72       49944      727     52824
BGP adj in                    :   788254     48    50853520   788508  50898224
BGP adj out                   :  2469178     88   217348416  2473666 217747680
BGP AS list                   :        2     48         112        2       112
BGP AS filter                 :        3     40         120        3       120
BGP AS filter str             :        3 variable       152        3       152
community                     :    28500     40     1140992    28605   1145256
community val                 :    28500 variable   2020416    28605   2026544
community str                 :    28499 variable   5443528    28603   5459008
extcommunity                  :      184     32        7360      186      7440
extcommunity val              :      184 variable      6592      186      6704
extcommunity str              :      184 variable     20960      185     21240
community-list                :        9     56         504        9       504
community-list name           :        9 variable       232        9       232
community-list entry          :       16     48         896       16       896
community-list handler        :        1    120         136        1       136
BGP transit attr              :        7     24         168        8       192
BGP transit val               :        7 variable       168        8       192
BGP nexthop                   :       52     72        3792       59      4296
BGP regexp                    :        3     64         216        3       216
BGP own address               :        6     16         144        6       144
BGP Filter Information        :       73 variable      1752       74      1776
Large Community               :      716     40       28704      729     29224
Large Community display string:      685 variable     40392      695     41088
Large Community value         :      716 variable     38448      729     39184
BGP Martian Address Intf String:        6 variable       144        6       144
BGP PBR Context               :        1     16          24        1        24
BGP EVPN instance information :        1     24          24        1        24
BGP RPKI Cache server         :   332299 variable  13463288   332300  16080520
--- qmem rfapi ---
Type                          : Current#   Size       Total     Max#  MaxBytes
NVE Configuration             :        1   2816        2824        1      2824
RFAPI Generic                 :        1    296         296        1       296
RFAPI Import Table            :        1    208         216        1       216

Memory statistics for watchfrr:
System allocator statistics:
  Total heap allocated:  664 KiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  549 KiB
  Free small blocks:     1312 bytes
  Free ordinary blocks:  115 KiB
  Ordinary blocks:       1
  Small blocks:          38
  Holding blocks:        0
(see system documentation for 'mallinfo' for meaning)
--- qmem libfrr ---
Type                          : Current#   Size       Total     Max#  MaxBytes
Buffer                        :        2     24          48        2        48
Buffer data                   :        1   4120        4120        1      4120
Host config                   :        1      9          24        1        24
Command Tokens                :      457     72       32952      458     33024
Command Token Text            :      362 variable     11760      362     11760
Command Token Help            :      362 variable      8704      362      8704
Command Argument              :        2 variable        48        3        72
Command Argument Name         :       62 variable      1488       63      1512
Graph                         :        7      8         168        8       192
Graph Node                    :      571     32       22904      573     22984
Hash                          :       20 variable       976       20       976
Hash Bucket                   :      183     32        7336      183      7336
Hash Index                    :       10 variable      5968       11      6040
Hook entry                    :        2     48         112        2       112
Link List                     :        5     40         200        8       320
Link Node                     :       15     24         360       52      1248
Logging                       :        1     72          72        1        72
Temporary memory              :        4 variable        96        6       192
Northbound Configuration      :        2     72         144        2       144
Thread                        :       10    168        1680       10      1680
Thread master                 :        3 variable     16712        3     16712
Thread Poll Info              :        2   8192       16400        2     16400
Thread stats                  :       10     72         752       10       752
Typed-heap array              :        1    576         584        1       584
Vector                        :     1161     16       28040     1164     28112
Vector index                  :     1161 variable     38024     1164     38064
VTY                           :        2 variable      9872        2      9872
--- qmem watchfrr ---
Type                          : Current#   Size       Total     Max#  MaxBytes
watchfrr daemon entry         :        3    136         408        3       408

Memory statistics for staticd:
System allocator statistics:
  Total heap allocated:  1068 KiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  987 KiB
  Free small blocks:     1408 bytes
  Free ordinary blocks:  81 KiB
  Ordinary blocks:       2
  Small blocks:          41
  Holding blocks:        0
(see system documentation for 'mallinfo' for meaning)
--- qmem libfrr ---
Type                          : Current#   Size       Total     Max#  MaxBytes
Buffer                        :        5     24         136        5       136
Buffer data                   :        1   4120        4120        1      4120
Host config                   :        2 variable        48        2        48
Command Tokens                :     1301     72       93720     1304     93952
Command Token Text            :      991 variable     31432      993     31496
Command Token Help            :      991 variable     23800      993     23848
Command Argument              :        2 variable        48        5       120
Command Argument Name         :      261 variable      6264      264      6336
Graph                         :       12      8         288       13       312
Graph Node                    :     1521     32       61160     1524     61280
Hash                          :      212 variable     10240      212     10240
Hash Bucket                   :      289     32       11560      289     11560
Hash Index                    :      106 variable     33296      107     33432
Hook entry                    :        2     48         112        2       112
Interface                     :       18    264        4768       18      4768
Connected                     :       22     48        1232       22      1232
Link List                     :       45     40        1816       49      1976
Link Node                     :      139     24        3384      189      4648
Logging                       :        1     72          72        1        72
Northbound Configuration      :        2     72         144        2       144
Prefix                        :       25     48        1416       25      1416
Stream                        :        2  27800       55600        2     55600
Route table                   :        4     56         240        4       240
Route node                    :       13 variable      1576       13      1576
Thread                        :        5    168         856        5       856
Thread master                 :        3 variable     16712        3     16712
Thread Poll Info              :        2   8192       16400        2     16400
Thread stats                  :        6     72         448        6       448
Typed-hash bucket             :        3 variable       472        3       472
Vector                        :     3071     16       73944     3076     74064
Vector index                  :     3071 variable     99288     3076     99600
VRF                           :        1    200         200        1       200
VRF bit-map                   :        3      8          72        3        72
VTY                           :        4 variable     19744        4     19744
Zclient                       :        1   3216        3224        1      3224
Redistribution instance IDs   :        3      2          72        3        72
--- qmem staticd ---
Type                          : Current#   Size       Total     Max#  MaxBytes
Static Route                  :        9    208        1944        9      1944

Versions

  • OS Kernel: Debuan GNU/Linux 10 (buster), Kernel 5.2.0-0.bpo.2-amd64
  • FRR Version 7.2 (official build)
@crami crami added the triage Needs further investigation label Dec 1, 2019
@crami
Copy link
Author

crami commented Dec 1, 2019

Screenshot from 2019-12-01 11-37-26

donaldsharp added a commit to donaldsharp/frr that referenced this issue Dec 1, 2019
@donaldsharp
bgpd: Fix memory leak in json output of show commands
1f83ed0 
When dumping a large bit of table data via bgp_show_table
and if there is no information to display for a particular
`struct bgp_node *` the data allocated via json_object_new_array()
is leaked.  Not a big deal on small tables but if you have a full
bgp feed and issue a show command that does not match any of
the route nodes ( say `vtysh -c "show bgp ipv4 large-community-list FOO"`)
then we will leak memory.

Before code change and issuing the above show bgp large-community-list command 15-20 times:
Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  > 2GB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  > 2GB
  Free small blocks:     31 MiB
  Free ordinary blocks:  616 KiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

After:

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  924 MiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  558 MiB
  Free small blocks:     26 MiB
  Free ordinary blocks:  340 MiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

Please note the 340mb of free ordinary blocks is from the fact I issued a
`show bgp ipv4 uni json` command and generated a large amount of data.

Fixes: FRRouting#5445
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
@donaldsharp donaldsharp mentioned this issue Dec 1, 2019
Merged
@ton31337 ton31337 added bgp bug and removed triage Needs further investigation labels Dec 1, 2019
donaldsharp added a commit to donaldsharp/frr that referenced this issue Dec 2, 2019
@donaldsharp
bgpd: Fix memory leak in json output of show commands
7e599e7 
When dumping a large bit of table data via bgp_show_table
and if there is no information to display for a particular
`struct bgp_node *` the data allocated via json_object_new_array()
is leaked.  Not a big deal on small tables but if you have a full
bgp feed and issue a show command that does not match any of
the route nodes ( say `vtysh -c "show bgp ipv4 large-community-list FOO"`)
then we will leak memory.

Before code change and issuing the above show bgp large-community-list command 15-20 times:
Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  > 2GB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  > 2GB
  Free small blocks:     31 MiB
  Free ordinary blocks:  616 KiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

After:

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  924 MiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  558 MiB
  Free small blocks:     26 MiB
  Free ordinary blocks:  340 MiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

Please note the 340mb of free ordinary blocks is from the fact I issued a
`show bgp ipv4 uni json` command and generated a large amount of data.

Fixes: FRRouting#5445
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
@donaldsharp donaldsharp mentioned this issue Dec 2, 2019
Merged
donaldsharp added a commit to donaldsharp/frr that referenced this issue Dec 2, 2019
@donaldsharp
bgpd: Fix memory leak in json output of show commands
9ac50be 
When dumping a large bit of table data via bgp_show_table
and if there is no information to display for a particular
`struct bgp_node *` the data allocated via json_object_new_array()
is leaked.  Not a big deal on small tables but if you have a full
bgp feed and issue a show command that does not match any of
the route nodes ( say `vtysh -c "show bgp ipv4 large-community-list FOO"`)
then we will leak memory.

Before code change and issuing the above show bgp large-community-list command 15-20 times:
Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  > 2GB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  > 2GB
  Free small blocks:     31 MiB
  Free ordinary blocks:  616 KiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

After:

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  924 MiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  558 MiB
  Free small blocks:     26 MiB
  Free ordinary blocks:  340 MiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

Please note the 340mb of free ordinary blocks is from the fact I issued a
`show bgp ipv4 uni json` command and generated a large amount of data.

Fixes: FRRouting#5445
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
@donaldsharp donaldsharp mentioned this issue Dec 2, 2019
Merged
donaldsharp added a commit to donaldsharp/frr that referenced this issue Dec 2, 2019
@donaldsharp
bgpd: Fix memory leak in json output of show commands
d6052e2 
When dumping a large bit of table data via bgp_show_table
and if there is no information to display for a particular
`struct bgp_node *` the data allocated via json_object_new_array()
is leaked.  Not a big deal on small tables but if you have a full
bgp feed and issue a show command that does not match any of
the route nodes ( say `vtysh -c "show bgp ipv4 large-community-list FOO"`)
then we will leak memory.

Before code change and issuing the above show bgp large-community-list command 15-20 times:
Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  > 2GB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  > 2GB
  Free small blocks:     31 MiB
  Free ordinary blocks:  616 KiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

After:

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  924 MiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  558 MiB
  Free small blocks:     26 MiB
  Free ordinary blocks:  340 MiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

Please note the 340mb of free ordinary blocks is from the fact I issued a
`show bgp ipv4 uni json` command and generated a large amount of data.

Fixes: FRRouting#5445
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
@donaldsharp donaldsharp mentioned this issue Dec 2, 2019
Merged
Spantik pushed a commit to Spantik/frr that referenced this issue Dec 2, 2019
@donaldsharp
bgpd: Fix memory leak in json output of show commands
e8f422a 
When dumping a large bit of table data via bgp_show_table
and if there is no information to display for a particular
`struct bgp_node *` the data allocated via json_object_new_array()
is leaked.  Not a big deal on small tables but if you have a full
bgp feed and issue a show command that does not match any of
the route nodes ( say `vtysh -c "show bgp ipv4 large-community-list FOO"`)
then we will leak memory.

Before code change and issuing the above show bgp large-community-list command 15-20 times:
Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  > 2GB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  > 2GB
  Free small blocks:     31 MiB
  Free ordinary blocks:  616 KiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

After:

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  924 MiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  558 MiB
  Free small blocks:     26 MiB
  Free ordinary blocks:  340 MiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

Please note the 340mb of free ordinary blocks is from the fact I issued a
`show bgp ipv4 uni json` command and generated a large amount of data.

Fixes: FRRouting#5445
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Spantik pushed a commit to Spantik/frr that referenced this issue Dec 2, 2019
@donaldsharp
bgpd: Fix memory leak in json output of show commands
55945dd 
When dumping a large bit of table data via bgp_show_table
and if there is no information to display for a particular
`struct bgp_node *` the data allocated via json_object_new_array()
is leaked.  Not a big deal on small tables but if you have a full
bgp feed and issue a show command that does not match any of
the route nodes ( say `vtysh -c "show bgp ipv4 large-community-list FOO"`)
then we will leak memory.

Before code change and issuing the above show bgp large-community-list command 15-20 times:
Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  > 2GB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  > 2GB
  Free small blocks:     31 MiB
  Free ordinary blocks:  616 KiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

After:

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  924 MiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  558 MiB
  Free small blocks:     26 MiB
  Free ordinary blocks:  340 MiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

Please note the 340mb of free ordinary blocks is from the fact I issued a
`show bgp ipv4 uni json` command and generated a large amount of data.

Fixes: FRRouting#5445
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
vishaldhingra pushed a commit to vishaldhingra/frr that referenced this issue Dec 3, 2019
@donaldsharp @vishaldhingra
bgpd: Fix memory leak in json output of show commands
99aeaae 
When dumping a large bit of table data via bgp_show_table
and if there is no information to display for a particular
`struct bgp_node *` the data allocated via json_object_new_array()
is leaked.  Not a big deal on small tables but if you have a full
bgp feed and issue a show command that does not match any of
the route nodes ( say `vtysh -c "show bgp ipv4 large-community-list FOO"`)
then we will leak memory.

Before code change and issuing the above show bgp large-community-list command 15-20 times:
Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  > 2GB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  > 2GB
  Free small blocks:     31 MiB
  Free ordinary blocks:  616 KiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

After:

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  924 MiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  558 MiB
  Free small blocks:     26 MiB
  Free ordinary blocks:  340 MiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

Please note the 340mb of free ordinary blocks is from the fact I issued a
`show bgp ipv4 uni json` command and generated a large amount of data.

Fixes: FRRouting#5445
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
vishaldhingra pushed a commit to vishaldhingra/frr that referenced this issue Dec 3, 2019
@donaldsharp @vishaldhingra
bgpd: Fix memory leak in json output of show commands
4d5ea60 
When dumping a large bit of table data via bgp_show_table
and if there is no information to display for a particular
`struct bgp_node *` the data allocated via json_object_new_array()
is leaked.  Not a big deal on small tables but if you have a full
bgp feed and issue a show command that does not match any of
the route nodes ( say `vtysh -c "show bgp ipv4 large-community-list FOO"`)
then we will leak memory.

Before code change and issuing the above show bgp large-community-list command 15-20 times:
Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  > 2GB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  > 2GB
  Free small blocks:     31 MiB
  Free ordinary blocks:  616 KiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

After:

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  924 MiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  558 MiB
  Free small blocks:     26 MiB
  Free ordinary blocks:  340 MiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

Please note the 340mb of free ordinary blocks is from the fact I issued a
`show bgp ipv4 uni json` command and generated a large amount of data.

Fixes: FRRouting#5445
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
vishaldhingra pushed a commit to vishaldhingra/frr that referenced this issue Dec 3, 2019
@donaldsharp @vishaldhingra
bgpd: Fix memory leak in json output of show commands
a81162e 
When dumping a large bit of table data via bgp_show_table
and if there is no information to display for a particular
`struct bgp_node *` the data allocated via json_object_new_array()
is leaked.  Not a big deal on small tables but if you have a full
bgp feed and issue a show command that does not match any of
the route nodes ( say `vtysh -c "show bgp ipv4 large-community-list FOO"`)
then we will leak memory.

Before code change and issuing the above show bgp large-community-list command 15-20 times:
Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  > 2GB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  > 2GB
  Free small blocks:     31 MiB
  Free ordinary blocks:  616 KiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

After:

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  924 MiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  558 MiB
  Free small blocks:     26 MiB
  Free ordinary blocks:  340 MiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

Please note the 340mb of free ordinary blocks is from the fact I issued a
`show bgp ipv4 uni json` command and generated a large amount of data.

Fixes: FRRouting#5445
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Spantik pushed a commit to Spantik/frr that referenced this issue Dec 9, 2019
@donaldsharp
bgpd: Fix memory leak in json output of show commands
862bfa5 
When dumping a large bit of table data via bgp_show_table
and if there is no information to display for a particular
`struct bgp_node *` the data allocated via json_object_new_array()
is leaked.  Not a big deal on small tables but if you have a full
bgp feed and issue a show command that does not match any of
the route nodes ( say `vtysh -c "show bgp ipv4 large-community-list FOO"`)
then we will leak memory.

Before code change and issuing the above show bgp large-community-list command 15-20 times:
Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  > 2GB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  > 2GB
  Free small blocks:     31 MiB
  Free ordinary blocks:  616 KiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

After:

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  924 MiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  558 MiB
  Free small blocks:     26 MiB
  Free ordinary blocks:  340 MiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

Please note the 340mb of free ordinary blocks is from the fact I issued a
`show bgp ipv4 uni json` command and generated a large amount of data.

Fixes: FRRouting#5445
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Spantik pushed a commit to Spantik/frr that referenced this issue Dec 9, 2019
@donaldsharp
bgpd: Fix memory leak in json output of show commands
1c8310b 
When dumping a large bit of table data via bgp_show_table
and if there is no information to display for a particular
`struct bgp_node *` the data allocated via json_object_new_array()
is leaked.  Not a big deal on small tables but if you have a full
bgp feed and issue a show command that does not match any of
the route nodes ( say `vtysh -c "show bgp ipv4 large-community-list FOO"`)
then we will leak memory.

Before code change and issuing the above show bgp large-community-list command 15-20 times:
Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  > 2GB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  > 2GB
  Free small blocks:     31 MiB
  Free ordinary blocks:  616 KiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

After:

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  924 MiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  558 MiB
  Free small blocks:     26 MiB
  Free ordinary blocks:  340 MiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

Please note the 340mb of free ordinary blocks is from the fact I issued a
`show bgp ipv4 uni json` command and generated a large amount of data.

Fixes: FRRouting#5445
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Spantik pushed a commit to Spantik/frr that referenced this issue Dec 10, 2019
@donaldsharp
bgpd: Fix memory leak in json output of show commands
1ec20c6 
When dumping a large bit of table data via bgp_show_table
and if there is no information to display for a particular
`struct bgp_node *` the data allocated via json_object_new_array()
is leaked.  Not a big deal on small tables but if you have a full
bgp feed and issue a show command that does not match any of
the route nodes ( say `vtysh -c "show bgp ipv4 large-community-list FOO"`)
then we will leak memory.

Before code change and issuing the above show bgp large-community-list command 15-20 times:
Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  > 2GB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  > 2GB
  Free small blocks:     31 MiB
  Free ordinary blocks:  616 KiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

After:

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  924 MiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  558 MiB
  Free small blocks:     26 MiB
  Free ordinary blocks:  340 MiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

Please note the 340mb of free ordinary blocks is from the fact I issued a
`show bgp ipv4 uni json` command and generated a large amount of data.

Fixes: FRRouting#5445
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Spantik pushed a commit to Spantik/frr that referenced this issue Dec 10, 2019
@donaldsharp
bgpd: Fix memory leak in json output of show commands
257b659 
When dumping a large bit of table data via bgp_show_table
and if there is no information to display for a particular
`struct bgp_node *` the data allocated via json_object_new_array()
is leaked.  Not a big deal on small tables but if you have a full
bgp feed and issue a show command that does not match any of
the route nodes ( say `vtysh -c "show bgp ipv4 large-community-list FOO"`)
then we will leak memory.

Before code change and issuing the above show bgp large-community-list command 15-20 times:
Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  > 2GB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  > 2GB
  Free small blocks:     31 MiB
  Free ordinary blocks:  616 KiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

After:

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  924 MiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  558 MiB
  Free small blocks:     26 MiB
  Free ordinary blocks:  340 MiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

Please note the 340mb of free ordinary blocks is from the fact I issued a
`show bgp ipv4 uni json` command and generated a large amount of data.

Fixes: FRRouting#5445
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Spantik pushed a commit to Spantik/frr that referenced this issue Dec 10, 2019
@donaldsharp
bgpd: Fix memory leak in json output of show commands
acd0e6b 
When dumping a large bit of table data via bgp_show_table
and if there is no information to display for a particular
`struct bgp_node *` the data allocated via json_object_new_array()
is leaked.  Not a big deal on small tables but if you have a full
bgp feed and issue a show command that does not match any of
the route nodes ( say `vtysh -c "show bgp ipv4 large-community-list FOO"`)
then we will leak memory.

Before code change and issuing the above show bgp large-community-list command 15-20 times:
Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  > 2GB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  > 2GB
  Free small blocks:     31 MiB
  Free ordinary blocks:  616 KiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

After:

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  924 MiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  558 MiB
  Free small blocks:     26 MiB
  Free ordinary blocks:  340 MiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

Please note the 340mb of free ordinary blocks is from the fact I issued a
`show bgp ipv4 uni json` command and generated a large amount of data.

Fixes: FRRouting#5445
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Spantik pushed a commit to Spantik/frr that referenced this issue Dec 10, 2019
@donaldsharp
bgpd: Fix memory leak in json output of show commands
36520ef 
When dumping a large bit of table data via bgp_show_table
and if there is no information to display for a particular
`struct bgp_node *` the data allocated via json_object_new_array()
is leaked.  Not a big deal on small tables but if you have a full
bgp feed and issue a show command that does not match any of
the route nodes ( say `vtysh -c "show bgp ipv4 large-community-list FOO"`)
then we will leak memory.

Before code change and issuing the above show bgp large-community-list command 15-20 times:
Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  > 2GB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  > 2GB
  Free small blocks:     31 MiB
  Free ordinary blocks:  616 KiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

After:

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  924 MiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  558 MiB
  Free small blocks:     26 MiB
  Free ordinary blocks:  340 MiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

Please note the 340mb of free ordinary blocks is from the fact I issued a
`show bgp ipv4 uni json` command and generated a large amount of data.

Fixes: FRRouting#5445
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Spantik pushed a commit to Spantik/frr that referenced this issue Dec 10, 2019
@donaldsharp
bgpd: Fix memory leak in json output of show commands
ec428b1 
When dumping a large bit of table data via bgp_show_table
and if there is no information to display for a particular
`struct bgp_node *` the data allocated via json_object_new_array()
is leaked.  Not a big deal on small tables but if you have a full
bgp feed and issue a show command that does not match any of
the route nodes ( say `vtysh -c "show bgp ipv4 large-community-list FOO"`)
then we will leak memory.

Before code change and issuing the above show bgp large-community-list command 15-20 times:
Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  > 2GB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  > 2GB
  Free small blocks:     31 MiB
  Free ordinary blocks:  616 KiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

After:

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  924 MiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  558 MiB
  Free small blocks:     26 MiB
  Free ordinary blocks:  340 MiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

Please note the 340mb of free ordinary blocks is from the fact I issued a
`show bgp ipv4 uni json` command and generated a large amount of data.

Fixes: FRRouting#5445
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Spantik pushed a commit to Spantik/frr that referenced this issue Dec 20, 2019
@donaldsharp
bgpd: Fix memory leak in json output of show commands
12cd8fc 
When dumping a large bit of table data via bgp_show_table
and if there is no information to display for a particular
`struct bgp_node *` the data allocated via json_object_new_array()
is leaked.  Not a big deal on small tables but if you have a full
bgp feed and issue a show command that does not match any of
the route nodes ( say `vtysh -c "show bgp ipv4 large-community-list FOO"`)
then we will leak memory.

Before code change and issuing the above show bgp large-community-list command 15-20 times:
Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  > 2GB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  > 2GB
  Free small blocks:     31 MiB
  Free ordinary blocks:  616 KiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

After:

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  924 MiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  558 MiB
  Free small blocks:     26 MiB
  Free ordinary blocks:  340 MiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

Please note the 340mb of free ordinary blocks is from the fact I issued a
`show bgp ipv4 uni json` command and generated a large amount of data.

Fixes: FRRouting#5445
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Spantik pushed a commit to Spantik/frr that referenced this issue Dec 20, 2019
@donaldsharp
bgpd: Fix memory leak in json output of show commands
f614670 
When dumping a large bit of table data via bgp_show_table
and if there is no information to display for a particular
`struct bgp_node *` the data allocated via json_object_new_array()
is leaked.  Not a big deal on small tables but if you have a full
bgp feed and issue a show command that does not match any of
the route nodes ( say `vtysh -c "show bgp ipv4 large-community-list FOO"`)
then we will leak memory.

Before code change and issuing the above show bgp large-community-list command 15-20 times:
Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  > 2GB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  > 2GB
  Free small blocks:     31 MiB
  Free ordinary blocks:  616 KiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

After:

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  924 MiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  558 MiB
  Free small blocks:     26 MiB
  Free ordinary blocks:  340 MiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

Please note the 340mb of free ordinary blocks is from the fact I issued a
`show bgp ipv4 uni json` command and generated a large amount of data.

Fixes: FRRouting#5445
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Spantik pushed a commit to Spantik/frr that referenced this issue Jan 20, 2020
@donaldsharp
bgpd: Fix memory leak in json output of show commands
6d5d8de 
When dumping a large bit of table data via bgp_show_table
and if there is no information to display for a particular
`struct bgp_node *` the data allocated via json_object_new_array()
is leaked.  Not a big deal on small tables but if you have a full
bgp feed and issue a show command that does not match any of
the route nodes ( say `vtysh -c "show bgp ipv4 large-community-list FOO"`)
then we will leak memory.

Before code change and issuing the above show bgp large-community-list command 15-20 times:
Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  > 2GB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  > 2GB
  Free small blocks:     31 MiB
  Free ordinary blocks:  616 KiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

After:

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  924 MiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  558 MiB
  Free small blocks:     26 MiB
  Free ordinary blocks:  340 MiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

Please note the 340mb of free ordinary blocks is from the fact I issued a
`show bgp ipv4 uni json` command and generated a large amount of data.

Fixes: FRRouting#5445
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
qlyoung pushed a commit to qlyoung/frr that referenced this issue Jun 17, 2020
@donaldsharp
bgpd: Fix memory leak in json output of show commands
04f9287 
When dumping a large bit of table data via bgp_show_table
and if there is no information to display for a particular
`struct bgp_node *` the data allocated via json_object_new_array()
is leaked.  Not a big deal on small tables but if you have a full
bgp feed and issue a show command that does not match any of
the route nodes ( say `vtysh -c "show bgp ipv4 large-community-list FOO"`)
then we will leak memory.

Before code change and issuing the above show bgp large-community-list command 15-20 times:
Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  > 2GB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  > 2GB
  Free small blocks:     31 MiB
  Free ordinary blocks:  616 KiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

After:

Memory statistics for bgpd:
System allocator statistics:
  Total heap allocated:  924 MiB
  Holding block headers: 0 bytes
  Used small blocks:     0 bytes
  Used ordinary blocks:  558 MiB
  Free small blocks:     26 MiB
  Free ordinary blocks:  340 MiB
  Ordinary blocks:       0
  Small blocks:          0
  Holding blocks:        0

Please note the 340mb of free ordinary blocks is from the fact I issued a
`show bgp ipv4 uni json` command and generated a large amount of data.

Fixes: FRRouting#5445
Ticket: CM-27537
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bgp bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

bgpd: Fix memory leak in json output of show commands donaldsharp/frr
2 participants
@crami @ton31337