-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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.
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
isis crash #4
Comments
do we have some pcap files for this? |
output.swp2.pcap.gz Multiple iterations of the crash hopefully included in the 2 pcap files. This is on r11 |
Valgrind caught it this time: ==7946== Invalid free() / delete / delete[] / realloc() |
So in isis_tlv.c we have this:
#ifdef EXTREME_TLV_DEBUG pnt is set off the stream_dup that lsp->pdu is set from, but we have a lsp->own_lsp set to true hence the crash. |
Commit 4fedc05 addresses the issue from happening. But I would like to see Christian comment on the further debugging I provided before closing to see if he thinks what he has done has sufficiently closed the loop holes. |
actually I was wrong, I just happened to recheck my test setup and am seeing the same core files. |
Resolved via 07f2fb1 |
* commit '4709b4faa43907ed9fcaf5920e56b6664f0523cf': bgpd: peer hash expands until we are out of memory
Signed-off-by: Daniel Walton <[email protected]> Reviewed-by: Donald Sharp <[email protected]> Ticket: CM-17175 If you are doing multipath in a VRF and bounce one of the multipaths for a prefix, bgp is not updating the zebra entry for that prefix with the new multipaths. We start with: cel-redxp-10# show bgp vrf RED ipv4 unicast 6.0.0.16/32 BGP routing table entry for 6.0.0.16/32 Paths: (4 available, best #4, table RED) Advertised to non peer-group peers: spine-1(swp1) spine-2(swp2) spine-3(swp3) spine-4(swp4) 104 65104 65002 fe80::202:ff:fe00:2d from spine-4(swp4) (6.0.0.12) (fe80::202:ff:fe00:2d) (used) Origin incomplete, localpref 100, valid, external, multipath, bestpath-from-AS 104 AddPath ID: RX 0, TX 21 Last update: Tue Aug 1 18:28:33 2017 102 65104 65002 fe80::202:ff:fe00:25 from spine-2(swp2) (6.0.0.10) (fe80::202:ff:fe00:25) (used) Origin incomplete, localpref 100, valid, external, multipath, bestpath-from-AS 102 AddPath ID: RX 0, TX 20 Last update: Tue Aug 1 18:28:33 2017 103 65104 65002 fe80::202:ff:fe00:29 from spine-3(swp3) (6.0.0.11) (fe80::202:ff:fe00:29) (used) Origin incomplete, localpref 100, valid, external, multipath, bestpath-from-AS 103 AddPath ID: RX 0, TX 17 Last update: Tue Aug 1 18:28:33 2017 101 65104 65002 fe80::202:ff:fe00:21 from spine-1(swp1) (6.0.0.9) (fe80::202:ff:fe00:21) (used) Origin incomplete, localpref 100, valid, external, multipath, bestpath-from-AS 101, best AddPath ID: RX 0, TX 8 Last update: Tue Aug 1 18:28:33 2017 cel-redxp-10# cel-redxp-10# show ip route vrf RED 6.0.0.16/32 Routing entry for 6.0.0.16/32 Known via "bgp", distance 20, metric 0, vrf RED, best Last update 00:00:25 ago * fe80::202:ff:fe00:21, via swp1 * fe80::202:ff:fe00:25, via swp2 * fe80::202:ff:fe00:29, via swp3 * fe80::202:ff:fe00:2d, via swp4 cel-redxp-10# And then on spine-1 we bounce all peers spine-1# clear ip bgp * spine-1# On the leaf (cel-redxp-10) we remove the route from spine-1 cel-redxp-10# show ip route vrf RED 6.0.0.16/32 Routing entry for 6.0.0.16/32 Known via "bgp", distance 20, metric 0, vrf RED, best Last update 00:00:01 ago * fe80::202:ff:fe00:25, via swp2 * fe80::202:ff:fe00:29, via swp3 * fe80::202:ff:fe00:2d, via swp4 cel-redxp-10# So far so good. The problem is when the session to spine-1 comes back up bgp will mark the flag from spine-1 as multipath but does not update zebra. We end up in a state where BGP has 4 paths flags as multipath but only 3 paths are in the RIB.
Signed-off-by: Daniel Walton <[email protected]> If you are doing multipath in a VRF and bounce one of the multipaths for a prefix, bgp is not updating the zebra entry for that prefix with the new multipaths. We start with: cel-redxp-10# show bgp vrf RED ipv4 unicast 6.0.0.16/32 BGP routing table entry for 6.0.0.16/32 Paths: (4 available, best #4, table RED) Advertised to non peer-group peers: spine-1(swp1) spine-2(swp2) spine-3(swp3) spine-4(swp4) 104 65104 65002 fe80::202:ff:fe00:2d from spine-4(swp4) (6.0.0.12) (fe80::202:ff:fe00:2d) (used) Origin incomplete, localpref 100, valid, external, multipath, bestpath-from-AS 104 AddPath ID: RX 0, TX 21 Last update: Tue Aug 1 18:28:33 2017 102 65104 65002 fe80::202:ff:fe00:25 from spine-2(swp2) (6.0.0.10) (fe80::202:ff:fe00:25) (used) Origin incomplete, localpref 100, valid, external, multipath, bestpath-from-AS 102 AddPath ID: RX 0, TX 20 Last update: Tue Aug 1 18:28:33 2017 103 65104 65002 fe80::202:ff:fe00:29 from spine-3(swp3) (6.0.0.11) (fe80::202:ff:fe00:29) (used) Origin incomplete, localpref 100, valid, external, multipath, bestpath-from-AS 103 AddPath ID: RX 0, TX 17 Last update: Tue Aug 1 18:28:33 2017 101 65104 65002 fe80::202:ff:fe00:21 from spine-1(swp1) (6.0.0.9) (fe80::202:ff:fe00:21) (used) Origin incomplete, localpref 100, valid, external, multipath, bestpath-from-AS 101, best AddPath ID: RX 0, TX 8 Last update: Tue Aug 1 18:28:33 2017 cel-redxp-10# cel-redxp-10# show ip route vrf RED 6.0.0.16/32 Routing entry for 6.0.0.16/32 Known via "bgp", distance 20, metric 0, vrf RED, best Last update 00:00:25 ago * fe80::202:ff:fe00:21, via swp1 * fe80::202:ff:fe00:25, via swp2 * fe80::202:ff:fe00:29, via swp3 * fe80::202:ff:fe00:2d, via swp4 cel-redxp-10# And then on spine-1 we bounce all peers spine-1# clear ip bgp * spine-1# On the leaf (cel-redxp-10) we remove the route from spine-1 cel-redxp-10# show ip route vrf RED 6.0.0.16/32 Routing entry for 6.0.0.16/32 Known via "bgp", distance 20, metric 0, vrf RED, best Last update 00:00:01 ago * fe80::202:ff:fe00:25, via swp2 * fe80::202:ff:fe00:29, via swp3 * fe80::202:ff:fe00:2d, via swp4 cel-redxp-10# So far so good. The problem is when the session to spine-1 comes back up bgp will mark the flag from spine-1 as `multipath` but does not update zebra. We end up in a state where BGP has 4 paths flags as multipath but only 3 paths are in the RIB.
More error stuff
Some bgp evpn memory contexts are not freed at the end of the bgp process. > ================================================================= > ==1208677==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 96 byte(s) in 2 object(s) allocated from: > #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f93ace77233 in qcalloc lib/memory.c:106 > FRRouting#2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084 > FRRouting#3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302 > FRRouting#4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347 > FRRouting#5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482 > FRRouting#6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091 > FRRouting#7 0x7f93acf8082d in event_call lib/event.c:1996 > FRRouting#8 0x7f93ace48931 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x563bb6880ae1 in main bgpd/bgp_main.c:557 > FRRouting#10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, the bgp evpn context may noy be used if adj rib in is unused. This may lead to memory leaks. Fix this by freeing the context in those corner cases. Signed-off-by: Philippe Guibert <[email protected]>
When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f358e877233 in qcalloc lib/memory.c:106 > FRRouting#2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > FRRouting#3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > FRRouting#4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > FRRouting#5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > FRRouting#6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > FRRouting#7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > FRRouting#8 0x7f358e98082d in event_call lib/event.c:1996 > FRRouting#9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > FRRouting#10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > FRRouting#11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <[email protected]> fixup bgpd: fix duplicate BGP instance created with unified config
Some bgp evpn memory contexts are not freed at the end of the bgp process. > ================================================================= > ==1208677==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 96 byte(s) in 2 object(s) allocated from: > #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f93ace77233 in qcalloc lib/memory.c:106 > FRRouting#2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084 > FRRouting#3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302 > FRRouting#4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347 > FRRouting#5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482 > FRRouting#6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091 > FRRouting#7 0x7f93acf8082d in event_call lib/event.c:1996 > FRRouting#8 0x7f93ace48931 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x563bb6880ae1 in main bgpd/bgp_main.c:557 > FRRouting#10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, the bgp evpn context may noy be used if adj rib in is unused. This may lead to memory leaks. Fix this by freeing the context in those corner cases. Signed-off-by: Philippe Guibert <[email protected]>
When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f358e877233 in qcalloc lib/memory.c:106 > FRRouting#2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > FRRouting#3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > FRRouting#4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > FRRouting#5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > FRRouting#6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > FRRouting#7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > FRRouting#8 0x7f358e98082d in event_call lib/event.c:1996 > FRRouting#9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > FRRouting#10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > FRRouting#11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <[email protected]> fixup bgpd: fix duplicate BGP instance created with unified config
Some bgp evpn memory contexts are not freed at the end of the bgp process. > ================================================================= > ==1208677==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 96 byte(s) in 2 object(s) allocated from: > #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f93ace77233 in qcalloc lib/memory.c:106 > FRRouting#2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084 > FRRouting#3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302 > FRRouting#4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347 > FRRouting#5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482 > FRRouting#6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091 > FRRouting#7 0x7f93acf8082d in event_call lib/event.c:1996 > FRRouting#8 0x7f93ace48931 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x563bb6880ae1 in main bgpd/bgp_main.c:557 > FRRouting#10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, the bgp evpn context may noy be used if adj rib in is unused. This may lead to memory leaks. Fix this by freeing the context in those corner cases. Signed-off-by: Philippe Guibert <[email protected]>
When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f358e877233 in qcalloc lib/memory.c:106 > FRRouting#2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > FRRouting#3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > FRRouting#4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > FRRouting#5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > FRRouting#6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > FRRouting#7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > FRRouting#8 0x7f358e98082d in event_call lib/event.c:1996 > FRRouting#9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > FRRouting#10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > FRRouting#11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <[email protected]> fixup bgpd: fix duplicate BGP instance created with unified config
Some bgp evpn memory contexts are not freed at the end of the bgp process. > ================================================================= > ==1208677==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 96 byte(s) in 2 object(s) allocated from: > #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f93ace77233 in qcalloc lib/memory.c:106 > FRRouting#2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084 > FRRouting#3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302 > FRRouting#4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347 > FRRouting#5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482 > FRRouting#6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091 > FRRouting#7 0x7f93acf8082d in event_call lib/event.c:1996 > FRRouting#8 0x7f93ace48931 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x563bb6880ae1 in main bgpd/bgp_main.c:557 > FRRouting#10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, the bgp evpn context may noy be used if adj rib in is unused. This may lead to memory leaks. Fix this by freeing the context in those corner cases. Signed-off-by: Philippe Guibert <[email protected]>
When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f358e877233 in qcalloc lib/memory.c:106 > FRRouting#2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > FRRouting#3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > FRRouting#4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > FRRouting#5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > FRRouting#6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > FRRouting#7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > FRRouting#8 0x7f358e98082d in event_call lib/event.c:1996 > FRRouting#9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > FRRouting#10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > FRRouting#11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <[email protected]> fixup bgpd: fix duplicate BGP instance created with unified config
Some bgp evpn memory contexts are not freed at the end of the bgp process. > ================================================================= > ==1208677==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 96 byte(s) in 2 object(s) allocated from: > #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f93ace77233 in qcalloc lib/memory.c:106 > FRRouting#2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084 > FRRouting#3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302 > FRRouting#4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347 > FRRouting#5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482 > FRRouting#6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091 > FRRouting#7 0x7f93acf8082d in event_call lib/event.c:1996 > FRRouting#8 0x7f93ace48931 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x563bb6880ae1 in main bgpd/bgp_main.c:557 > FRRouting#10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, the bgp evpn context may noy be used if adj rib in is unused. This may lead to memory leaks. Fix this by freeing the context in those corner cases. Signed-off-by: Philippe Guibert <[email protected]>
The following memory leak is observed when running bgp_bmp test. > ==614841==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 81 byte(s) in 1 object(s) allocated from: > #0 0x7f0e9f2b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 > FRRouting#1 0x7f0e9ec771f8 in qmalloc lib/memory.c:101 > FRRouting#2 0x7f0e9e5a2f89 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2211 > FRRouting#3 0x7f0e9e5a31a8 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2247 > FRRouting#4 0x7f0e9e5b0325 in bmp_bgp_attribute_updated_instance bgpd/bgp_bmp.c:3476 > FRRouting#5 0x7f0e9e5b0661 in bmp_bgp_attribute_updated bgpd/bgp_bmp.c:3526 > FRRouting#6 0x7f0e9e5b08ae in bmp_routerid_update bgpd/bgp_bmp.c:3547 > FRRouting#7 0x55cdc4bcbd88 in hook_call_bgp_routerid_update bgpd/bgpd.c:89 > FRRouting#8 0x55cdc4bccf0b in bgp_router_id_set bgpd/bgpd.c:305 > FRRouting#9 0x55cdc4bcd87d in bgp_router_id_zebra_bump bgpd/bgpd.c:393 > FRRouting#10 0x55cdc4ba87d5 in bgp_router_id_update bgpd/bgp_zebra.c:99 > FRRouting#11 0x7f0e9ede3f0b in zclient_read lib/zclient.c:4626 > FRRouting#12 0x7f0e9ed8074d in event_call lib/event.c:1996 > FRRouting#13 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232 > FRRouting#14 0x55cdc48a9a27 in main bgpd/bgp_main.c:555 > FRRouting#15 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > Direct leak of 81 byte(s) in 1 object(s) allocated from: > #0 0x7f0e9f2b4887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 > FRRouting#1 0x7f0e9ec771f8 in qmalloc lib/memory.c:101 > FRRouting#2 0x7f0e9e5a2ed8 in bmp_bgp_peer_vrf bgpd/bgp_bmp.c:2207 > FRRouting#3 0x7f0e9e5a31a8 in bmp_bgp_update_vrf_status bgpd/bgp_bmp.c:2247 > FRRouting#4 0x7f0e9e5b0325 in bmp_bgp_attribute_updated_instance bgpd/bgp_bmp.c:3476 > FRRouting#5 0x7f0e9e5b0661 in bmp_bgp_attribute_updated bgpd/bgp_bmp.c:3526 > FRRouting#6 0x7f0e9e5b08ae in bmp_routerid_update bgpd/bgp_bmp.c:3547 > FRRouting#7 0x55cdc4bcbd88 in hook_call_bgp_routerid_update bgpd/bgpd.c:89 > FRRouting#8 0x55cdc4bccf0b in bgp_router_id_set bgpd/bgpd.c:305 > FRRouting#9 0x55cdc4bcd87d in bgp_router_id_zebra_bump bgpd/bgpd.c:393 > FRRouting#10 0x55cdc4ba87d5 in bgp_router_id_update bgpd/bgp_zebra.c:99 > FRRouting#11 0x7f0e9ede3f0b in zclient_read lib/zclient.c:4626 > FRRouting#12 0x7f0e9ed8074d in event_call lib/event.c:1996 > FRRouting#13 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232 > FRRouting#14 0x55cdc48a9a27 in main bgpd/bgp_main.c:555 > FRRouting#15 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > Direct leak of 64 byte(s) in 1 object(s) allocated from: > #0 0x7f0e9f2b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f0e9ec77235 in qcalloc lib/memory.c:106 > FRRouting#2 0x7f0e9e5a498d in bmp_imported_bgp_get bgpd/bgp_bmp.c:2441 > FRRouting#3 0x7f0e9e5acbed in bmp_import_vrf_magic bgpd/bgp_bmp.c:2855 > FRRouting#4 0x7f0e9e5a7f97 in bmp_import_vrf bgpd/bgp_bmp_clippy.c:147 > FRRouting#5 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003 > FRRouting#6 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062 > FRRouting#7 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228 > FRRouting#8 0x7f0e9ed90bf0 in vty_command lib/vty.c:626 > FRRouting#9 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389 > FRRouting#10 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408 > FRRouting#11 0x7f0e9ed8074d in event_call lib/event.c:1996 > FRRouting#12 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232 > FRRouting#13 0x55cdc48a9a27 in main bgpd/bgp_main.c:555 > FRRouting#14 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > Direct leak of 6 byte(s) in 1 object(s) allocated from: > #0 0x7f0e9f25b9a7 in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:454 > FRRouting#1 0x7f0e9ec772fa in qstrdup lib/memory.c:118 > FRRouting#2 0x55cdc4b57d54 in af_rd_vpn_export_magic bgpd/bgp_vty.c:9814 > FRRouting#3 0x55cdc4b288d7 in af_rd_vpn_export bgpd/bgp_vty_clippy.c:3493 > FRRouting#4 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003 > FRRouting#5 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062 > FRRouting#6 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228 > FRRouting#7 0x7f0e9ed90bf0 in vty_command lib/vty.c:626 > FRRouting#8 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389 > FRRouting#9 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408 > FRRouting#10 0x7f0e9ed8074d in event_call lib/event.c:1996 > FRRouting#11 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232 > FRRouting#12 0x55cdc48a9a27 in main bgpd/bgp_main.c:555 > FRRouting#13 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > Indirect leak of 5 byte(s) in 1 object(s) allocated from: > #0 0x7f0e9f25b9a7 in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:454 > FRRouting#1 0x7f0e9ec772fa in qstrdup lib/memory.c:118 > FRRouting#2 0x7f0e9e5a49ae in bmp_imported_bgp_get bgpd/bgp_bmp.c:2443 > FRRouting#3 0x7f0e9e5acbed in bmp_import_vrf_magic bgpd/bgp_bmp.c:2855 > FRRouting#4 0x7f0e9e5a7f97 in bmp_import_vrf bgpd/bgp_bmp_clippy.c:147 > FRRouting#5 0x7f0e9ebb1178 in cmd_execute_command_real lib/command.c:1003 > FRRouting#6 0x7f0e9ebb1505 in cmd_execute_command lib/command.c:1062 > FRRouting#7 0x7f0e9ebb21d7 in cmd_execute lib/command.c:1228 > FRRouting#8 0x7f0e9ed90bf0 in vty_command lib/vty.c:626 > FRRouting#9 0x7f0e9ed95ad5 in vty_execute lib/vty.c:1389 > FRRouting#10 0x7f0e9ed9c01e in vtysh_read lib/vty.c:2408 > FRRouting#11 0x7f0e9ed8074d in event_call lib/event.c:1996 > FRRouting#12 0x7f0e9ec48933 in frr_run lib/libfrr.c:1232 > FRRouting#13 0x55cdc48a9a27 in main bgpd/bgp_main.c:555 > FRRouting#14 0x7f0e9e629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > > SUMMARY: AddressSanitizer: 237 byte(s) leaked in 5 allocation(s). Fix this by freeing the missing memory block that helps building the open message to send to remote bmp collector. Signed-off-by: Philippe Guibert <[email protected]>
> ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f73891cb146 bp 0x7ffca86584c0 sp 0x7ffca8658490 T0) > ==837617==The signal is caused by a READ memory access. > ==837617==Hint: address points to the zero page. > #0 0x7f73891cb146 in bmp_targets_const_next bgpd/bgp_bmp.c:149 > FRRouting#1 0x7f73891cb1a5 in bmp_targets_next bgpd/bgp_bmp.c:149 > FRRouting#2 0x7f73891e875a in _bmp_vrf_state_changed_internal bgpd/bgp_bmp.c:3520 > FRRouting#3 0x7f73891e8922 in bmp_vrf_itf_state_changed bgpd/bgp_bmp.c:3566 > FRRouting#4 0x55e511af8d1b in hook_call_bgp_vrf_status_changed bgpd/bgp_zebra.c:64 > FRRouting#5 0x55e511afa304 in bgp_ifp_up bgpd/bgp_zebra.c:234 > FRRouting#6 0x7f738981c193 in hook_call_if_up lib/if.c:57 > FRRouting#7 0x7f738981d09a in if_up_via_zapi lib/if.c:203 > FRRouting#8 0x7f73899d6f54 in zclient_interface_up lib/zclient.c:2671 > FRRouting#9 0x7f73899e3e5a in zclient_read lib/zclient.c:4624 > FRRouting#10 0x7f738998078d in event_call lib/event.c:1996 > FRRouting#11 0x7f7389848933 in frr_run lib/libfrr.c:1232 > FRRouting#12 0x55e5117f7ae1 in main bgpd/bgp_main.c:557 > FRRouting#13 0x7f7389229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 > FRRouting#14 0x7f7389229e3f in __libc_start_main_impl ../csu/libc-start.c:392 > FRRouting#15 0x55e5117f4234 in _start (/usr/lib/frr/bgpd+0x2ec234) Signed-off-by: Philippe Guibert <[email protected]>
There is no control on the returned nexthop group entry, when finding pic contexts. Actually the pic context can resolve over itself, and this may lead to stack overflow: The below can be found by generalizing the search of pic nhe for all nexthops and not only for srv6 contexts. > root@ubuntu2204hwe:~/frr# AddressSanitizer:DEADLYSIGNAL > ================================================================= > ==247856==ERROR: AddressSanitizer: stack-overflow on address 0x7ffe4e6dcff8 (pc 0x561e05bb5653 bp 0x7ffe4e6dd020 sp 0x7ffe4e6dd000 T0) > #0 0x561e05bb5653 in zebra_nhg_install_kernel zebra/zebra_nhg.c:3310 > FRRouting#1 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329 > FRRouting#2 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329 > FRRouting#3 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329 > FRRouting#4 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329 > FRRouting#5 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329 > FRRouting#6 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329 > FRRouting#7 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329 > FRRouting#8 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329 > FRRouting#9 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329 > FRRouting#10 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329 > FRRouting#11 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329 > FRRouting#12 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329 > FRRouting#13 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329 > FRRouting#14 0x561e05bb572d in zebra_nhg_install_kernel zebra/zebra_nhg.c:3329 Fix this by not returning a nexthop group entry when creation is necessary for pic context. Add a check when the pic creation is not needed and the returned nhe has the same identifier as the requested nhe. Signed-off-by: Philippe Guibert <[email protected]>
When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f358e877233 in qcalloc lib/memory.c:106 > FRRouting#2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > FRRouting#3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > FRRouting#4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > FRRouting#5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > FRRouting#6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > FRRouting#7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > FRRouting#8 0x7f358e98082d in event_call lib/event.c:1996 > FRRouting#9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > FRRouting#10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > FRRouting#11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <[email protected]> fixup bgpd: fix duplicate BGP instance created with unified config
Some bgp evpn memory contexts are not freed at the end of the bgp process. > ================================================================= > ==1208677==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 96 byte(s) in 2 object(s) allocated from: > #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f93ace77233 in qcalloc lib/memory.c:106 > FRRouting#2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084 > FRRouting#3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302 > FRRouting#4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347 > FRRouting#5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482 > FRRouting#6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091 > FRRouting#7 0x7f93acf8082d in event_call lib/event.c:1996 > FRRouting#8 0x7f93ace48931 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x563bb6880ae1 in main bgpd/bgp_main.c:557 > FRRouting#10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, the bgp evpn context may noy be used if adj rib in is unused. This may lead to memory leaks. Fix this by freeing the context in those corner cases. Signed-off-by: Philippe Guibert <[email protected]>
Some bgp evpn memory contexts are not freed at the end of the bgp process. > ================================================================= > ==1208677==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 96 byte(s) in 2 object(s) allocated from: > #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f93ace77233 in qcalloc lib/memory.c:106 > FRRouting#2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084 > FRRouting#3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302 > FRRouting#4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347 > FRRouting#5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482 > FRRouting#6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091 > FRRouting#7 0x7f93acf8082d in event_call lib/event.c:1996 > FRRouting#8 0x7f93ace48931 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x563bb6880ae1 in main bgpd/bgp_main.c:557 > FRRouting#10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, the bgp evpn context may noy be used if adj rib in is unused. This may lead to memory leaks. Fix this by freeing the context in those corner cases. Signed-off-by: Philippe Guibert <[email protected]>
When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f358e877233 in qcalloc lib/memory.c:106 > FRRouting#2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > FRRouting#3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > FRRouting#4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > FRRouting#5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > FRRouting#6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > FRRouting#7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > FRRouting#8 0x7f358e98082d in event_call lib/event.c:1996 > FRRouting#9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > FRRouting#10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > FRRouting#11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <[email protected]>
Some bgp evpn memory contexts are not freed at the end of the bgp process. > ================================================================= > ==1208677==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 96 byte(s) in 2 object(s) allocated from: > #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f93ace77233 in qcalloc lib/memory.c:106 > FRRouting#2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084 > FRRouting#3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302 > FRRouting#4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347 > FRRouting#5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482 > FRRouting#6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091 > FRRouting#7 0x7f93acf8082d in event_call lib/event.c:1996 > FRRouting#8 0x7f93ace48931 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x563bb6880ae1 in main bgpd/bgp_main.c:557 > FRRouting#10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, the bgp evpn context may noy be used if adj rib in is unused. This may lead to memory leaks. Fix this by freeing the context in those corner cases. Signed-off-by: Philippe Guibert <[email protected]>
When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f358e877233 in qcalloc lib/memory.c:106 > FRRouting#2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > FRRouting#3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > FRRouting#4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > FRRouting#5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > FRRouting#6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > FRRouting#7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > FRRouting#8 0x7f358e98082d in event_call lib/event.c:1996 > FRRouting#9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > FRRouting#10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > FRRouting#11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <[email protected]>
Some bgp evpn memory contexts are not freed at the end of the bgp process. > ================================================================= > ==1208677==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 96 byte(s) in 2 object(s) allocated from: > #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f93ace77233 in qcalloc lib/memory.c:106 > FRRouting#2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084 > FRRouting#3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302 > FRRouting#4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347 > FRRouting#5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482 > FRRouting#6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091 > FRRouting#7 0x7f93acf8082d in event_call lib/event.c:1996 > FRRouting#8 0x7f93ace48931 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x563bb6880ae1 in main bgpd/bgp_main.c:557 > FRRouting#10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, the bgp evpn context may noy be used if adj rib in is unused. This may lead to memory leaks. Fix this by freeing the context in those corner cases. Signed-off-by: Philippe Guibert <[email protected]>
When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f358e877233 in qcalloc lib/memory.c:106 > FRRouting#2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > FRRouting#3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > FRRouting#4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > FRRouting#5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > FRRouting#6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > FRRouting#7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > FRRouting#8 0x7f358e98082d in event_call lib/event.c:1996 > FRRouting#9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > FRRouting#10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > FRRouting#11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <[email protected]>
Some bgp evpn memory contexts are not freed at the end of the bgp process. > ================================================================= > ==1208677==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 96 byte(s) in 2 object(s) allocated from: > #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f93ace77233 in qcalloc lib/memory.c:106 > FRRouting#2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084 > FRRouting#3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302 > FRRouting#4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347 > FRRouting#5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482 > FRRouting#6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091 > FRRouting#7 0x7f93acf8082d in event_call lib/event.c:1996 > FRRouting#8 0x7f93ace48931 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x563bb6880ae1 in main bgpd/bgp_main.c:557 > FRRouting#10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, the bgp evpn context may noy be used if adj rib in is unused. This may lead to memory leaks. Fix this by freeing the context in those corner cases. Signed-off-by: Philippe Guibert <[email protected]>
When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f358e877233 in qcalloc lib/memory.c:106 > FRRouting#2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > FRRouting#3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > FRRouting#4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > FRRouting#5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > FRRouting#6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > FRRouting#7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > FRRouting#8 0x7f358e98082d in event_call lib/event.c:1996 > FRRouting#9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > FRRouting#10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > FRRouting#11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <[email protected]>
Some bgp evpn memory contexts are not freed at the end of the bgp process. > ================================================================= > ==1208677==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 96 byte(s) in 2 object(s) allocated from: > #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f93ace77233 in qcalloc lib/memory.c:106 > FRRouting#2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084 > FRRouting#3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302 > FRRouting#4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347 > FRRouting#5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482 > FRRouting#6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091 > FRRouting#7 0x7f93acf8082d in event_call lib/event.c:1996 > FRRouting#8 0x7f93ace48931 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x563bb6880ae1 in main bgpd/bgp_main.c:557 > FRRouting#10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, the bgp evpn context may noy be used if adj rib in is unused. This may lead to memory leaks. Fix this by freeing the context in those corner cases. Signed-off-by: Philippe Guibert <[email protected]>
When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f358e877233 in qcalloc lib/memory.c:106 > FRRouting#2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > FRRouting#3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > FRRouting#4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > FRRouting#5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > FRRouting#6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > FRRouting#7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > FRRouting#8 0x7f358e98082d in event_call lib/event.c:1996 > FRRouting#9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > FRRouting#10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > FRRouting#11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <[email protected]>
Some bgp evpn memory contexts are not freed at the end of the bgp process. > ================================================================= > ==1208677==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 96 byte(s) in 2 object(s) allocated from: > #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f93ace77233 in qcalloc lib/memory.c:106 > FRRouting#2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084 > FRRouting#3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302 > FRRouting#4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347 > FRRouting#5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482 > FRRouting#6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091 > FRRouting#7 0x7f93acf8082d in event_call lib/event.c:1996 > FRRouting#8 0x7f93ace48931 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x563bb6880ae1 in main bgpd/bgp_main.c:557 > FRRouting#10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, the bgp evpn context may noy be used if adj rib in is unused. This may lead to memory leaks. Fix this by freeing the context in those corner cases. Signed-off-by: Philippe Guibert <[email protected]>
When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f358e877233 in qcalloc lib/memory.c:106 > FRRouting#2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > FRRouting#3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > FRRouting#4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > FRRouting#5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > FRRouting#6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > FRRouting#7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > FRRouting#8 0x7f358e98082d in event_call lib/event.c:1996 > FRRouting#9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > FRRouting#10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > FRRouting#11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <[email protected]>
When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f358e877233 in qcalloc lib/memory.c:106 > FRRouting#2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > FRRouting#3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > FRRouting#4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > FRRouting#5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > FRRouting#6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > FRRouting#7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > FRRouting#8 0x7f358e98082d in event_call lib/event.c:1996 > FRRouting#9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > FRRouting#10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > FRRouting#11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <[email protected]> fixup bgpd: fix duplicate BGP instance created with unified config
Some bgp evpn memory contexts are not freed at the end of the bgp process. > ================================================================= > ==1208677==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 96 byte(s) in 2 object(s) allocated from: > #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f93ace77233 in qcalloc lib/memory.c:106 > FRRouting#2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084 > FRRouting#3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302 > FRRouting#4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347 > FRRouting#5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482 > FRRouting#6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091 > FRRouting#7 0x7f93acf8082d in event_call lib/event.c:1996 > FRRouting#8 0x7f93ace48931 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x563bb6880ae1 in main bgpd/bgp_main.c:557 > FRRouting#10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, the bgp evpn context may noy be used if adj rib in is unused. This may lead to memory leaks. Fix this by freeing the context in those corner cases. Signed-off-by: Philippe Guibert <[email protected]>
Some bgp evpn memory contexts are not freed at the end of the bgp process. > ================================================================= > ==1208677==ERROR: LeakSanitizer: detected memory leaks > > Direct leak of 96 byte(s) in 2 object(s) allocated from: > #0 0x7f93ad4b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f93ace77233 in qcalloc lib/memory.c:106 > FRRouting#2 0x563bb68f4df1 in process_type5_route bgpd/bgp_evpn.c:5084 > FRRouting#3 0x563bb68fb663 in bgp_nlri_parse_evpn bgpd/bgp_evpn.c:6302 > FRRouting#4 0x563bb69ea2a9 in bgp_nlri_parse bgpd/bgp_packet.c:347 > FRRouting#5 0x563bb69f7716 in bgp_update_receive bgpd/bgp_packet.c:2482 > FRRouting#6 0x563bb6a04d3b in bgp_process_packet bgpd/bgp_packet.c:4091 > FRRouting#7 0x7f93acf8082d in event_call lib/event.c:1996 > FRRouting#8 0x7f93ace48931 in frr_run lib/libfrr.c:1232 > FRRouting#9 0x563bb6880ae1 in main bgpd/bgp_main.c:557 > FRRouting#10 0x7f93ac829d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, the bgp evpn context may noy be used if adj rib in is unused. This may lead to memory leaks. Fix this by freeing the context in those corner cases. Signed-off-by: Philippe Guibert <[email protected]>
When running the bgp_evpn_rt5 setup with unified config, memory leak about a non deleted BGP instance happens. > root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105 > > ================================================================= > ==1164105==ERROR: LeakSanitizer: detected memory leaks > > Indirect leak of 12496 byte(s) in 1 object(s) allocated from: > #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 > FRRouting#1 0x7f358e877233 in qcalloc lib/memory.c:106 > FRRouting#2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405 > FRRouting#3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805 > FRRouting#4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603 > FRRouting#5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032 > FRRouting#6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204 > FRRouting#7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626 > FRRouting#8 0x7f358e98082d in event_call lib/event.c:1996 > FRRouting#9 0x7f358e848931 in frr_run lib/libfrr.c:1232 > FRRouting#10 0x55d06c60eae1 in main bgpd/bgp_main.c:557 > FRRouting#11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Actually, a BGP VRF Instance is created in auto mode when creating the global BGP instance for the L3 VNI. And again, an other BGP VRF instance is created. Fix this by ensuring that a non existing BGP instance is not present. If it is present, and with auto mode or in hidden mode, then override the AS value. Fixes: f153b9a ("bgpd: Ignore auto created VRF BGP instances") Signed-off-by: Philippe Guibert <[email protected]>
[6:35]
[6:35]
[6:36]
In the above topology we are seeing crashes in isis on r11, r4, and r7
[6:36]
config on r10:
[6:37]
The text was updated successfully, but these errors were encountered: