Fix for the command "show ip ospf vrf NAME graceful-restart helper".
FRR did not show information by vrf's name.
If i have router ospf vrf red, vtysh's command
'show ip ospf vrf red graceful-restart helper' will not show anything.
But command 'show ip ospf vrf all graceful-restart helper' will work
normally. This fix fixes the display of information by vrf's name.
Example:
frr1# show ip ospf vrf vrf-1 graceful-restart helper
VRF Name: vrf-1
OSPF Router with ID (192.168.255.81)
Graceful restart helper support enabled.
Strict LSA check is enabled.
Helper supported for Planned and Unplanned Restarts.
Supported Graceful restart interval: 1800(in seconds).
Signed-off-by: teletajp <teletajp@yandex.ru>
Release memory allocated for the IPv4 address during the interface reset.
The addition of `free(babel_ifp->ipv4)` ensures proper cleanup, preventing
potential memory leaks.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in babel_topo1.test_babel_topo1/r2.asan.babeld.18864
=================================================================
==18864==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 8 byte(s) in 2 object(s) allocated from:
#0 0x7f3f4531bb40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x55c1806cb28d in babel_interface_address_add babeld/babel_interface.c:112
#2 0x7f3f44de9e29 in zclient_read lib/zclient.c:4425
#3 0x7f3f44db9dfa in event_call lib/event.c:1965
#4 0x7f3f44cfd3bf in frr_run lib/libfrr.c:1214
#5 0x55c1806cc81b in main babeld/babel_main.c:202
#6 0x7f3f4451fc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 8 byte(s) leaked in 2 allocation(s).
***********************************************************************************
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
Implement a callback function for memory cleanup of sharp_nh_tracker.
Specifically, set `sharp_nh_tracker_free` as the deletion function for the `sg.nhs` list.
This ensures proper cleanup of resources when elements are removed.
The ASan leak log for reference:
```
***********************************************************************************
Address Sanitizer Error detected in zebra_nht_resolution.test_verify_nh_resolution/r1.asan.sharpd.32320
=================================================================
==32320==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 64 byte(s) in 1 object(s) allocated from:
#0 0x7f4ee812ad28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f4ee7b291cc in qcalloc lib/memory.c:105
#2 0x5582be672011 in sharp_nh_tracker_get sharpd/sharp_nht.c:36
#3 0x5582be680b42 in watch_nexthop_v4_magic sharpd/sharp_vty.c:139
#4 0x5582be680b42 in watch_nexthop_v4 sharpd/sharp_vty_clippy.c:192
#5 0x7f4ee7aac0b1 in cmd_execute_command_real lib/command.c:978
#6 0x7f4ee7aac575 in cmd_execute_command lib/command.c:1036
#7 0x7f4ee7aac9f4 in cmd_execute lib/command.c:1203
#8 0x7f4ee7bd50bb in vty_command lib/vty.c:594
#9 0x7f4ee7bd5566 in vty_execute lib/vty.c:1357
#10 0x7f4ee7bdde37 in vtysh_read lib/vty.c:2365
#11 0x7f4ee7bc8dfa in event_call lib/event.c:1965
#12 0x7f4ee7b0c3bf in frr_run lib/libfrr.c:1214
#13 0x5582be671252 in main sharpd/sharp_main.c:188
#14 0x7f4ee6f1bc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 64 byte(s) leaked in 1 allocation(s).
***********************************************************************************
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
Fix memory leaks by allocating `json_segs` conditionally on `nexthop->nh_srv6->seg6_segs`.
The previous code allocated memory even when not in use or attached to the JSON tree.
The ASan leak log for reference:
```
Direct leak of 3240 byte(s) in 45 object(s) allocated from:
#0 0x7f6e84a35d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f6e83de9e6f in json_object_new_array (/lib/x86_64-linux-gnu/libjson-c.so.3+0x3e6f)
#2 0x564dcab5c1a6 in vty_show_ip_route zebra/zebra_vty.c:705
#3 0x564dcab5cc71 in do_show_route_helper zebra/zebra_vty.c:955
#4 0x564dcab5d418 in do_show_ip_route zebra/zebra_vty.c:1039
#5 0x564dcab63ee5 in show_route_magic zebra/zebra_vty.c:1878
#6 0x564dcab63ee5 in show_route zebra/zebra_vty_clippy.c:659
#7 0x7f6e843b6fb1 in cmd_execute_command_real lib/command.c:978
#8 0x7f6e843b7475 in cmd_execute_command lib/command.c:1036
#9 0x7f6e843b78f4 in cmd_execute lib/command.c:1203
#10 0x7f6e844dfe3b in vty_command lib/vty.c:594
#11 0x7f6e844e02e6 in vty_execute lib/vty.c:1357
#12 0x7f6e844e8bb7 in vtysh_read lib/vty.c:2365
#13 0x7f6e844d3b7a in event_call lib/event.c:1965
#14 0x7f6e844172b0 in frr_run lib/libfrr.c:1214
#15 0x564dcaa50e81 in main zebra/main.c:488
#16 0x7f6e837f7c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 11520 byte(s) in 45 object(s) allocated from:
#0 0x7f6e84a35d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f6e83de88c0 in array_list_new (/lib/x86_64-linux-gnu/libjson-c.so.3+0x28c0)
Indirect leak of 1080 byte(s) in 45 object(s) allocated from:
#0 0x7f6e84a35d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7f6e83de8897 in array_list_new (/lib/x86_64-linux-gnu/libjson-c.so.3+0x2897)
```
Signed-off-by: Keelan Cannoo <keelan.cannoo@icloud.com>
Signed-off-by: ryndia <dindyalsarvesh@gmail.com>
For some series of calls in FREEBSD setting the SO_RCVBUF size will
always fail under freebsd. This is no bueno since the
setsockopt_so_recvbuf call goes into an infinite loop.
(gdb) bt
0 setsockopt () at setsockopt.S:4
1 0x0000000083065870 in setsockopt_so_recvbuf (sock=15, size=0) at lib/sockopt.c:26
2 0x00000000002bd200 in ospf_ifp_sock_init (ifp=<optimized out>, ifp@entry=0x8d1dd500) at ospfd/ospf_network.c:290
3 0x00000000002ad1e0 in ospf_if_new (ospf=0x8eefc000, ifp=0x8d1dd500, p=0x8eecf1c0) at ospfd/ospf_interface.c:276
4 0x0000000000304ee0 in add_ospf_interface (co=0x8eecbe10, area=0x8d192100) at ospfd/ospfd.c:1115
5 0x00000000003050fc in ospf_network_run_interface (ospf=0x8eefc000, ifp=0x8d1dd500, p=0x80ff63f8, given_area=0x8d192100)
at ospfd/ospfd.c:1460
6 ospf_network_run (p=0x80ff63f8, area=0x8d192100) at ospfd/ospfd.c:1474
7 ospf_network_set (ospf=ospf@entry=0x8eefc000, p=p@entry=0x80ff63f8, area_id=..., df=<optimized out>) at ospfd/ospfd.c:1247
8 0x00000000002e876c in ospf_network_area (self=<optimized out>, vty=0x8eef3180, argc=<optimized out>, argv=<optimized out>)
at ospfd/ospf_vty.c:560
9 0x0000000083006f24 in cmd_execute_command_real (vline=vline@entry=0x8eee9100, vty=vty@entry=0x8eef3180, cmd=<optimized out>,
cmd@entry=0x0, up_level=<optimized out>) at lib/command.c:978
10 0x0000000083006b30 in cmd_execute_command (vline=0x8eee9100, vty=vty@entry=0x8eef3180, cmd=cmd@entry=0x0, vtysh=vtysh@entry=0)
at lib/command.c:1037
11 0x0000000083007044 in cmd_execute (vty=vty@entry=0x8eef3180, cmd=cmd@entry=0x8eefb000 "network 192.168.64.0/24 area 0.0.0.0",
matched=0x0, vtysh=0) at lib/command.c:1203
12 0x000000008307e9cc in vty_command (vty=0x8eef3180, buf=0x8eefb000 "network 192.168.64.0/24 area 0.0.0.0") at lib/vty.c:594
13 vty_execute (vty=vty@entry=0x8eef3180) at lib/vty.c:1357
14 0x000000008307ce40 in vtysh_read (thread=<optimized out>) at lib/vty.c:2365
15 0x0000000083073db0 in event_call (thread=thread@entry=0x80ff88a0) at lib/event.c:1965
16 0x000000008302c604 in frr_run (master=0x8d188140) at lib/libfrr.c:1214
17 0x000000000029c330 in main (argc=6, argv=<optimized out>) at ospfd/ospf_main.c:252
(gdb)
Force the setsockopt function to quit when the value we are passing no
longer makes any sense.
Fixes: #14790
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The function aspath_remove_private_asns was using an aspath to perform some operation and didnt free it after usage leading to the leak below.
***********************************************************************************
Address Sanitizer Error detected in bgp_remove_private_as_route_map.test_bgp_remove_private_as_route_map/r2.asan.bgpd.27074
=================================================================
==27074==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 80 byte(s) in 2 object(s) allocated from:
#0 0x7fd0a4b95d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7fd0a45932ff in qcalloc lib/memory.c:105
#2 0x562b630b44cc in aspath_dup bgpd/bgp_aspath.c:689
#3 0x562b62f48498 in route_set_aspath_prepend bgpd/bgp_routemap.c:2283
#4 0x7fd0a45ec39a in route_map_apply_ext lib/routemap.c:2690
#5 0x562b62efbb1f in subgroup_announce_check bgpd/bgp_route.c:2434
#6 0x562b62efd4e2 in subgroup_process_announce_selected bgpd/bgp_route.c:2990
#7 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765
#8 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818
#9 0x562b62f6ae90 in subgroup_coalesce_timer bgpd/bgp_updgrp_adv.c:368
#10 0x7fd0a463322a in event_call lib/event.c:1970
#11 0x7fd0a4576566 in frr_run lib/libfrr.c:1214
#12 0x562b62dbd8f1 in main bgpd/bgp_main.c:510
#13 0x7fd0a35b8c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Direct leak of 80 byte(s) in 2 object(s) allocated from:
#0 0x7fd0a4b95d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7fd0a45932ff in qcalloc lib/memory.c:105
#2 0x562b630b44cc in aspath_dup bgpd/bgp_aspath.c:689
#3 0x562b62f48498 in route_set_aspath_prepend bgpd/bgp_routemap.c:2283
#4 0x7fd0a45ec39a in route_map_apply_ext lib/routemap.c:2690
#5 0x562b62efbb1f in subgroup_announce_check bgpd/bgp_route.c:2434
#6 0x562b62efd4e2 in subgroup_process_announce_selected bgpd/bgp_route.c:2990
#7 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765
#8 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818
#9 0x562b62f5b844 in updgrp_policy_update_walkcb bgpd/bgp_updgrp.c:1685
#10 0x562b62f59442 in update_group_walkcb bgpd/bgp_updgrp.c:1721
#11 0x7fd0a455a7aa in hash_walk lib/hash.c:270
#12 0x562b62f64a48 in update_group_af_walk bgpd/bgp_updgrp.c:2062
#13 0x562b62f6508c in update_group_walk bgpd/bgp_updgrp.c:2071
#14 0x562b62f6520c in update_group_policy_update bgpd/bgp_updgrp.c:1769
#15 0x562b62f4c2be in bgp_route_map_process_update bgpd/bgp_routemap.c:4501
#16 0x562b62f4d81a in bgp_route_map_process_update_cb bgpd/bgp_routemap.c:4683
#17 0x7fd0a45ed7e8 in route_map_walk_update_list lib/routemap.c:870
#18 0x562b62f337a2 in bgp_route_map_update_timer bgpd/bgp_routemap.c:4695
#19 0x7fd0a463322a in event_call lib/event.c:1970
#20 0x7fd0a4576566 in frr_run lib/libfrr.c:1214
#21 0x562b62dbd8f1 in main bgpd/bgp_main.c:510
#22 0x7fd0a35b8c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 64 byte(s) in 2 object(s) allocated from:
#0 0x7fd0a4b95b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7fd0a459301f in qmalloc lib/memory.c:100
#2 0x562b630b313f in aspath_make_str_count bgpd/bgp_aspath.c:551
#3 0x562b630b3ecf in aspath_str_update bgpd/bgp_aspath.c:659
#4 0x562b630b88b7 in aspath_prepend bgpd/bgp_aspath.c:1484
#5 0x562b62f484a8 in route_set_aspath_prepend bgpd/bgp_routemap.c:2289
#6 0x7fd0a45ec39a in route_map_apply_ext lib/routemap.c:2690
#7 0x562b62efbb1f in subgroup_announce_check bgpd/bgp_route.c:2434
#8 0x562b62efd4e2 in subgroup_process_announce_selected bgpd/bgp_route.c:2990
#9 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765
#10 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818
#11 0x562b62f6ae90 in subgroup_coalesce_timer bgpd/bgp_updgrp_adv.c:368
#12 0x7fd0a463322a in event_call lib/event.c:1970
#13 0x7fd0a4576566 in frr_run lib/libfrr.c:1214
#14 0x562b62dbd8f1 in main bgpd/bgp_main.c:510
#15 0x7fd0a35b8c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 64 byte(s) in 2 object(s) allocated from:
#0 0x7fd0a4b95b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7fd0a459301f in qmalloc lib/memory.c:100
#2 0x562b630b313f in aspath_make_str_count bgpd/bgp_aspath.c:551
#3 0x562b630b3ecf in aspath_str_update bgpd/bgp_aspath.c:659
#4 0x562b630b88b7 in aspath_prepend bgpd/bgp_aspath.c:1484
#5 0x562b62f484a8 in route_set_aspath_prepend bgpd/bgp_routemap.c:2289
#6 0x7fd0a45ec39a in route_map_apply_ext lib/routemap.c:2690
#7 0x562b62efbb1f in subgroup_announce_check bgpd/bgp_route.c:2434
#8 0x562b62efd4e2 in subgroup_process_announce_selected bgpd/bgp_route.c:2990
#9 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765
#10 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818
#11 0x562b62f5b844 in updgrp_policy_update_walkcb bgpd/bgp_updgrp.c:1685
#12 0x562b62f59442 in update_group_walkcb bgpd/bgp_updgrp.c:1721
#13 0x7fd0a455a7aa in hash_walk lib/hash.c:270
#14 0x562b62f64a48 in update_group_af_walk bgpd/bgp_updgrp.c:2062
#15 0x562b62f6508c in update_group_walk bgpd/bgp_updgrp.c:2071
#16 0x562b62f6520c in update_group_policy_update bgpd/bgp_updgrp.c:1769
#17 0x562b62f4c2be in bgp_route_map_process_update bgpd/bgp_routemap.c:4501
#18 0x562b62f4d81a in bgp_route_map_process_update_cb bgpd/bgp_routemap.c:4683
#19 0x7fd0a45ed7e8 in route_map_walk_update_list lib/routemap.c:870
#20 0x562b62f337a2 in bgp_route_map_update_timer bgpd/bgp_routemap.c:4695
#21 0x7fd0a463322a in event_call lib/event.c:1970
#22 0x7fd0a4576566 in frr_run lib/libfrr.c:1214
#23 0x562b62dbd8f1 in main bgpd/bgp_main.c:510
#24 0x7fd0a35b8c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 48 byte(s) in 2 object(s) allocated from:
#0 0x7fd0a4b95d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7fd0a45932ff in qcalloc lib/memory.c:105
#2 0x562b630b280d in assegment_new bgpd/bgp_aspath.c:105
#3 0x562b630b28f7 in assegment_dup bgpd/bgp_aspath.c:145
#4 0x562b630b29e8 in assegment_dup_all bgpd/bgp_aspath.c:162
#5 0x562b630b8895 in aspath_prepend bgpd/bgp_aspath.c:1483
#6 0x562b62f484a8 in route_set_aspath_prepend bgpd/bgp_routemap.c:2289
#7 0x7fd0a45ec39a in route_map_apply_ext lib/routemap.c:2690
#8 0x562b62efbb1f in subgroup_announce_check bgpd/bgp_route.c:2434
#9 0x562b62efd4e2 in subgroup_process_announce_selected bgpd/bgp_route.c:2990
#10 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765
#11 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818
#12 0x562b62f5b844 in updgrp_policy_update_walkcb bgpd/bgp_updgrp.c:1685
#13 0x562b62f59442 in update_group_walkcb bgpd/bgp_updgrp.c:1721
#14 0x7fd0a455a7aa in hash_walk lib/hash.c:270
#15 0x562b62f64a48 in update_group_af_walk bgpd/bgp_updgrp.c:2062
#16 0x562b62f6508c in update_group_walk bgpd/bgp_updgrp.c:2071
#17 0x562b62f6520c in update_group_policy_update bgpd/bgp_updgrp.c:1769
#18 0x562b62f4c2be in bgp_route_map_process_update bgpd/bgp_routemap.c:4501
#19 0x562b62f4d81a in bgp_route_map_process_update_cb bgpd/bgp_routemap.c:4683
#20 0x7fd0a45ed7e8 in route_map_walk_update_list lib/routemap.c:870
#21 0x562b62f337a2 in bgp_route_map_update_timer bgpd/bgp_routemap.c:4695
#22 0x7fd0a463322a in event_call lib/event.c:1970
#23 0x7fd0a4576566 in frr_run lib/libfrr.c:1214
#24 0x562b62dbd8f1 in main bgpd/bgp_main.c:510
#25 0x7fd0a35b8c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 48 byte(s) in 2 object(s) allocated from:
#0 0x7fd0a4b95d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
#1 0x7fd0a45932ff in qcalloc lib/memory.c:105
#2 0x562b630b280d in assegment_new bgpd/bgp_aspath.c:105
#3 0x562b630b28f7 in assegment_dup bgpd/bgp_aspath.c:145
#4 0x562b630b29e8 in assegment_dup_all bgpd/bgp_aspath.c:162
#5 0x562b630b8895 in aspath_prepend bgpd/bgp_aspath.c:1483
#6 0x562b62f484a8 in route_set_aspath_prepend bgpd/bgp_routemap.c:2289
#7 0x7fd0a45ec39a in route_map_apply_ext lib/routemap.c:2690
#8 0x562b62efbb1f in subgroup_announce_check bgpd/bgp_route.c:2434
#9 0x562b62efd4e2 in subgroup_process_announce_selected bgpd/bgp_route.c:2990
#10 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765
#11 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818
#12 0x562b62f6ae90 in subgroup_coalesce_timer bgpd/bgp_updgrp_adv.c:368
#13 0x7fd0a463322a in event_call lib/event.c:1970
#14 0x7fd0a4576566 in frr_run lib/libfrr.c:1214
#15 0x562b62dbd8f1 in main bgpd/bgp_main.c:510
#16 0x7fd0a35b8c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 16 byte(s) in 2 object(s) allocated from:
#0 0x7fd0a4b95b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7fd0a459301f in qmalloc lib/memory.c:100
#2 0x562b630b2879 in assegment_data_new bgpd/bgp_aspath.c:83
#3 0x562b630b2879 in assegment_new bgpd/bgp_aspath.c:108
#4 0x562b630b28f7 in assegment_dup bgpd/bgp_aspath.c:145
#5 0x562b630b29e8 in assegment_dup_all bgpd/bgp_aspath.c:162
#6 0x562b630b8895 in aspath_prepend bgpd/bgp_aspath.c:1483
#7 0x562b62f484a8 in route_set_aspath_prepend bgpd/bgp_routemap.c:2289
#8 0x7fd0a45ec39a in route_map_apply_ext lib/routemap.c:2690
#9 0x562b62efbb1f in subgroup_announce_check bgpd/bgp_route.c:2434
#10 0x562b62efd4e2 in subgroup_process_announce_selected bgpd/bgp_route.c:2990
#11 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765
#12 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818
#13 0x562b62f6ae90 in subgroup_coalesce_timer bgpd/bgp_updgrp_adv.c:368
#14 0x7fd0a463322a in event_call lib/event.c:1970
#15 0x7fd0a4576566 in frr_run lib/libfrr.c:1214
#16 0x562b62dbd8f1 in main bgpd/bgp_main.c:510
#17 0x7fd0a35b8c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
Indirect leak of 16 byte(s) in 2 object(s) allocated from:
#0 0x7fd0a4b95b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x7fd0a459301f in qmalloc lib/memory.c:100
#2 0x562b630b2879 in assegment_data_new bgpd/bgp_aspath.c:83
#3 0x562b630b2879 in assegment_new bgpd/bgp_aspath.c:108
#4 0x562b630b28f7 in assegment_dup bgpd/bgp_aspath.c:145
#5 0x562b630b29e8 in assegment_dup_all bgpd/bgp_aspath.c:162
#6 0x562b630b8895 in aspath_prepend bgpd/bgp_aspath.c:1483
#7 0x562b62f484a8 in route_set_aspath_prepend bgpd/bgp_routemap.c:2289
#8 0x7fd0a45ec39a in route_map_apply_ext lib/routemap.c:2690
#9 0x562b62efbb1f in subgroup_announce_check bgpd/bgp_route.c:2434
#10 0x562b62efd4e2 in subgroup_process_announce_selected bgpd/bgp_route.c:2990
#11 0x562b62f6a829 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:765
#12 0x562b62f6acbb in subgroup_announce_route bgpd/bgp_updgrp_adv.c:818
#13 0x562b62f5b844 in updgrp_policy_update_walkcb bgpd/bgp_updgrp.c:1685
#14 0x562b62f59442 in update_group_walkcb bgpd/bgp_updgrp.c:1721
#15 0x7fd0a455a7aa in hash_walk lib/hash.c:270
#16 0x562b62f64a48 in update_group_af_walk bgpd/bgp_updgrp.c:2062
#17 0x562b62f6508c in update_group_walk bgpd/bgp_updgrp.c:2071
#18 0x562b62f6520c in update_group_policy_update bgpd/bgp_updgrp.c:1769
#19 0x562b62f4c2be in bgp_route_map_process_update bgpd/bgp_routemap.c:4501
#20 0x562b62f4d81a in bgp_route_map_process_update_cb bgpd/bgp_routemap.c:4683
#21 0x7fd0a45ed7e8 in route_map_walk_update_list lib/routemap.c:870
#22 0x562b62f337a2 in bgp_route_map_update_timer bgpd/bgp_routemap.c:4695
#23 0x7fd0a463322a in event_call lib/event.c:1970
#24 0x7fd0a4576566 in frr_run lib/libfrr.c:1214
#25 0x562b62dbd8f1 in main bgpd/bgp_main.c:510
#26 0x7fd0a35b8c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
SUMMARY: AddressSanitizer: 416 byte(s) leaked in 16 allocation(s).
***********************************************************************************
Signed-off-by: ryndia <dindyalsarvesh@gmail.com>
Problem Statement:
========================
Mentioning few of the leaks here:
=3843268== 6 bytes in 3 blocks are still reachable in loss record 1 of 29
==3843268== at 0x483C855: malloc (vg_replace_malloc.c:381)
==3843268== by 0x489ED0E: qmalloc (memory.c:106)
==3843268== by 0x48DE8DB: redist_add_instance (zclient.c:125)
==3843268== by 0x48DF561: zclient_init (zclient.c:647)
==3843268== by 0x14FFA3: pim_zebra_init (pim_zebra.c:527)
==3843268== by 0x11D021: main (pim6_main.c:178)
==3843268==
==3843268== 24 bytes in 1 blocks are still reachable in loss record 2 of 29
==3843268== at 0x484147B: calloc (vg_replace_malloc.c:1328)
==3843268== by 0x489EE03: qcalloc (memory.c:111)
==3843268== by 0x4878DDE: buffer_new (buffer.c:72)
==3843268== by 0x48DE7BF: zclient_new (zclient.c:75)
==3843268== by 0x14FF1D: pim_zebra_init (pim_zebra.c:516)
==3843268== by 0x11D021: main (pim6_main.c:178)
==3843268==
==3843268== 24 bytes in 1 blocks are still reachable in loss record 3 of 29
==3843268== at 0x484147B: calloc (vg_replace_malloc.c:1328)
==3843268== by 0x489EE03: qcalloc (memory.c:111)
==3843268== by 0x4878DDE: buffer_new (buffer.c:72)
==3843268== by 0x48DE7BF: zclient_new (zclient.c:75)
==3843268== by 0x150A3D: zclient_lookup_new (pim_zlookup.c:131)
==3843268== by 0x11D021: main (pim6_main.c:178)
RCA:
=======================
Memory is allocated when the daemon started but
it is not freed when terminated.
Fix:
=======================
Freeing the memory when daemon goes down.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
CID 1570969 Overrun
/bgpd/bgp_snmp_bgp4v2.c: 534 in bgp4v2PathAttrLookup()
/bgpd/bgp_snmp_bgp4v2.c: 575 in bgp4v2PathAttrLookup()
/bgpd/bgp_snmp_bgp4v2.c: 514 in bgp4v2PathAttrLookup()
>>> CID 1570969: (OVERRUN)
>>> Overrunning array "bgp->rib" of 4 64-byte elements at element index 4 (byte offset 319) using index "afi" (which evaluates to 4).
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
Let's use the natural data structure in bgp for the prefix display
instead of a bunch of places where we call a translator function.
The %pBD does this and actually ensures data is correct.
Also fix a few spots in bgp_zebra.c where the cast to a NULL
pointer causes the catcher functionality to not work and fix
the resulting crash that resulted.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
a) nl_batch_tx_buf was not being freed
b) the mlag_fifo was not being freed
c) the vrf->ns_ctxt was not being freed
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
a) The cleanup of zclient on shutdown was not being
done
b) Cleanup vrf shutdown
c) Cleanup some lists
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
sharpd: Cleanup shutdown of vrf and some lists
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
`nb_cli_apply_changes` can be called with base xpath which should be
prepended to xpaths of every change in a transaction. This base xpath is
respected by regular northbound CLI but not by mgmtd. This commit fixes
the problem.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Batch IDs are only used to verify that all messages were received and
processed by a backend. It's not necessary to do that as we use reliable
stream transport - messages can't be dropped or received out of order.
This commit also fixes possible race condition that can happen if
one backend process messages slower than other backends.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
I recieve the following error with GCC 9.4.0:
```
In file included from /usr/include/string.h:495,
from ./lib/zebra.h:23,
from bgpd/bgp_snmp_bgp4v2.c:7:
In function ‘memset’,
inlined from ‘bgp4v2PathAttrLookup’ at bgpd/bgp_snmp_bgp4v2.c:605:3,
inlined from ‘bgp4v2PathAttrTable’ at bgpd/bgp_snmp_bgp4v2.c:747:9:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:71:10: error: ‘__builtin_memset’ offset [9, 20] from the object at ‘paddr’ is out of the bounds of referenced subobject ‘_v4_addr’ with type ‘struct in_addr’ at offset 4 [-Werror=array-bounds]
71 | return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
- These are just normal reachable allocs from inside external library code;
however, when running valgrind with memleak types "all" in order to find FRR
specific leaks (from memory.h) these are the only other reported leaks. Makes
easier checking and fixing.
Signed-off-by: Christian Hopps <chopps@labn.net>
- Cannot have 2 cmd_node's with same .node number. Install the mgmtd
client library debug nodes (client frontend and client backend) using
new unique node numbers. Fixes memleaks.
- Fix "debug mgmt client backend" to generate correct config (and not
for frontend).
Signed-off-by: Christian Hopps <chopps@labn.net>
mgmtd frees all non-NULL change->value variables at the end of every
commit. We shouldn't assign change->value with data returned by libyang
to prevent freeing of library-allocated memory.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
