| Commit message (Collapse) | Author | Files | Lines |
|---|
|
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
|
|
Previously we just raised an error for the test file with possibly all tests
passing. Now we fail any test that produces new backtraces or cores. This
just works a lot better with analysis and even CI.
Also be less verbose to the console after failure runs, just show error
level and above logs. The log files still capture all levels (DEBUG).
Signed-off-by: Christian Hopps <chopps@labn.net>
|
|
Signed-off-by: Christian Hopps <chopps@labn.net>
|
|
There's a workaround in the code from a bug from back in 2004, it ends
and re-enters config mode anytime an `exit` is done from a level below
the top-level config node (e.g., from a `router isis` node). We need to
re-enter config mode with or without a lock according to how we actually
entered it to begin with.
fixes #13920
Signed-off-by: Christian Hopps <chopps@labn.net>
|
|
The lock/unlocks are being done short-circuit so they are never pending;
however, the handling of the unlock notification was always resuming the command
if pending was set. In all cases pending is set for another command. For example
implicit commit locks then when notified its done unlocks which was clearing the
set-config pending flag and resuming that command incorrectly.
Signed-off-by: Christian Hopps <chopps@labn.net>
|
|
When running bgp_always_compare_med, I am frequently seeing a crash
After running with valgrind I am seeing this and a invalid write
immediately after this as well.
==311743== Invalid read of size 2
==311743== at 0x4992421: route_map_counter_decrement (routemap.c:3308)
==311743== by 0x35664D: peer_route_map_unset (bgpd.c:7259)
==311743== by 0x306546: peer_route_map_unset_vty (bgp_vty.c:8037)
==311743== by 0x3066AC: no_neighbor_route_map (bgp_vty.c:8081)
==311743== by 0x49078DE: cmd_execute_command_real (command.c:990)
==311743== by 0x4907A63: cmd_execute_command (command.c:1050)
==311743== by 0x490801F: cmd_execute (command.c:1217)
==311743== by 0x49C5535: vty_command (vty.c:551)
==311743== by 0x49C7459: vty_execute (vty.c:1314)
==311743== by 0x49C97D1: vtysh_read (vty.c:2223)
==311743== by 0x49BE5E2: event_call (event.c:1995)
==311743== by 0x494786C: frr_run (libfrr.c:1204)
==311743== by 0x1F7655: main (bgp_main.c:505)
==311743== Address 0x9ec2180 is 64 bytes inside a block of size 120 free'd
==311743== at 0x484B27F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==311743== by 0x495A1BA: qfree (memory.c:130)
==311743== by 0x498D412: route_map_free_map (routemap.c:748)
==311743== by 0x498D176: route_map_add (routemap.c:672)
==311743== by 0x498D79B: route_map_get (routemap.c:857)
==311743== by 0x499C256: lib_route_map_create (routemap_northbound.c:102)
==311743== by 0x49702D8: nb_callback_create (northbound.c:1234)
==311743== by 0x497107F: nb_callback_configuration (northbound.c:1578)
==311743== by 0x4971693: nb_transaction_process (northbound.c:1709)
==311743== by 0x496FCF4: nb_candidate_commit_apply (northbound.c:1103)
==311743== by 0x496FE4E: nb_candidate_commit (northbound.c:1136)
==311743== by 0x497798F: nb_cli_classic_commit (northbound_cli.c:49)
==311743== by 0x4977B4F: nb_cli_pending_commit_check (northbound_cli.c:88)
==311743== by 0x49078C1: cmd_execute_command_real (command.c:987)
==311743== by 0x4907B44: cmd_execute_command (command.c:1068)
==311743== by 0x490801F: cmd_execute (command.c:1217)
==311743== by 0x49C5535: vty_command (vty.c:551)
==311743== by 0x49C7459: vty_execute (vty.c:1314)
==311743== by 0x49C97D1: vtysh_read (vty.c:2223)
==311743== by 0x49BE5E2: event_call (event.c:1995)
==311743== by 0x494786C: frr_run (libfrr.c:1204)
==311743== by 0x1F7655: main (bgp_main.c:505)
==311743== Block was alloc'd at
==311743== at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==311743== by 0x495A068: qcalloc (memory.c:105)
==311743== by 0x498D0C8: route_map_new (routemap.c:646)
==311743== by 0x498D128: route_map_add (routemap.c:658)
==311743== by 0x498D79B: route_map_get (routemap.c:857)
==311743== by 0x499C256: lib_route_map_create (routemap_northbound.c:102)
==311743== by 0x49702D8: nb_callback_create (northbound.c:1234)
==311743== by 0x497107F: nb_callback_configuration (northbound.c:1578)
==311743== by 0x4971693: nb_transaction_process (northbound.c:1709)
==311743== by 0x496FCF4: nb_candidate_commit_apply (northbound.c:1103)
==311743== by 0x496FE4E: nb_candidate_commit (northbound.c:1136)
==311743== by 0x497798F: nb_cli_classic_commit (northbound_cli.c:49)
==311743== by 0x4977B4F: nb_cli_pending_commit_check (northbound_cli.c:88)
==311743== by 0x49078C1: cmd_execute_command_real (command.c:987)
==311743== by 0x4907B44: cmd_execute_command (command.c:1068)
==311743== by 0x490801F: cmd_execute (command.c:1217)
==311743== by 0x49C5535: vty_command (vty.c:551)
==311743== by 0x49C7459: vty_execute (vty.c:1314)
==311743== by 0x49C97D1: vtysh_read (vty.c:2223)
==311743== by 0x49BE5E2: event_call (event.c:1995)
==311743== by 0x494786C: frr_run (libfrr.c:1204)
Effectively the route_map that is being stored has been freed already
but we have not cleaned up properly yet. Go through and clean the
code up by ensuring that the pointer actually exists instead of trusting
it does when doing the decrement operation.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Signed-off-by: Christian Hopps <chopps@labn.net>
|
|
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
Currently, "on-match (next|goto)" only works if already present in a
route-map entry when the route-map is applied to the routes. However, if
the command is added to an existing route-map entry, the route-map is
not reapplied to the routes in order to accommodate the changes. And
service restart is needed. The problem is that setting the command
doesn't signal about the change to the listener (i.e. to a routing
daemon).
With this fix, signal to the listener about addition of "on-match
(next|goto)" to a route-map entry.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
|
|
`bnc->ifindex` should not be with 0 ( IFINDEX_INTERNAL ), so we can ignore
the wrong interface to make it safe.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
|
|
Currently the vrf change procedure for the deleted interface is after
its deletion, it causes problem for upper daemons.
Here is the problem of `bgp`:
After deletion of one **irrelevant** interface in the same vrf, its
`ifindex` is set to 0. And then, the vrf change procedure will send
"ZEBRA_INTERFACE_DOWN" to `bgpd`.
Normally, `bgp_nht_ifp_table_handle()` should igore this message for
no correlation. However, it wrongly matched `ifindex` of 0, and removed
the related routes for the down `bnc`.
Adjust the location of the vrf change procedure to fix this issue.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
|
|
Make the ospf6_lsa_unlock take the same parameters
that the ospf_lsa_unlock does to make it consistent
and to also ensure that no-one can make the mistake
of getting the pointer cleared up.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
It is unnecessary to do the bool calculation for expression.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
|
|
Signed-off-by: Alexander Sohn <github@asohn.de>
|
|
Adjust one debug info, separate the ip address from it. Just like it is processed
in `redistribute_update()`.
Before:
```
34:1375.75.75.75/32: Redist del: re 0x55c1112067e0 (0:static), new re 0x55c1112de7c0 (0:static)
```
After:
```
(34:13):75.75.75.75/32: Redist del: re 0x55c1112067e0 (0:static), new re 0x55c1112de7c0 (0:static)
```
Signed-off-by: anlan_cs <vic.lan@pica8.com>
|
|
fix the error path.
Signed-off-by: xzheng <zhengxiang311019@163.com>
|
|
No gmtime() allowed - use gmtime_r()
Signed-off-by: Mark Stapp <mjs@labn.net>
|
|
Add a test-case to the NHRP test that installs routes over the
NHRP tunnel endpoint routes. This confirms that zebra will use
NHRP routes when validating incoming routes from other daemons
(sharpd in this test).
Signed-off-by: Mark Stapp <mjs@labn.net>
|
|
Add a config option so that sharpd can install routes without
the ALLOW_RECURSION flag, matching IGP behavior.
The default remains 'recursion'.
Signed-off-by: Mark Stapp <mjs@labn.net>
|
|
Treat NHRP-installed routes as valid, as if they were
CONNECTED routes, when checking candidate routes'
nexthops for validity. This allows use of NHRP by an
IGP, for example, that doesn't normally want recursive
nexthop resolution.
Signed-off-by: Mark Stapp <mjs@labn.net>
|
|
Clean up use of a nexthop pointer - seemed inconsistent.
Signed-off-by: Mark Stapp <mjs@labn.net>
|
|
Check if vrf_lookup_by_id() didn't return a NULL before dereferencing in
flor_err().
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
Use the same logic as zebra_if_netconf_update_ctx().
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
It's already checked at the bottom of the function.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
bgp_zebra_tm_connect calls bgp_zebra_get_table_range which
just used the global zclient. Which of course still had
us exposing the global zclient to read and drop important
data from zebra. This fixes commit 787c61e03c760ffdb422bfc44c72d83fb451e0c8
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
bgp_zebra_tm_connect calls bgp_zebra_get_table_range which
just used the global zclient. Which of course still had
us exposing the global zclient to read and drop important
data from zebra. This fixes commit 787c61e03c760ffdb422bfc44c72d83fb451e0c8
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
The changes allow the test to correctly pass in case the connection
between two peers is be established in less than 0.5 seconds after the
delayopen timer expires.
Signed-off-by: David Schweizer <dschweizer@opensourcerouting.org>
|
|
Code is looking up the nlsock to generate the batch messages
and then looking it up again to get the response. Let's
just look it up one time.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Attempt to set the hold time in the bgp flowspec exabgp
config. In addition it was noticed that upstream bgp_flowspec
tests are still not negotiating peering within the time frame
specified. This is because the first tcp packet is missed
and no keepalive/hold time are negotiated and exabgp will
not attempt a reconnect for quite some time. Make this
test slower when things go south.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
The isis_tilfa_topo1 test is failing because insufficient time was
given for isis to converge on the system under system load. Extend
the time and decrease the hello-interval timers to give it more
of a chance to converge.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
The test is failing because it assumes a json key
is always present when it is not. Test for it
before having the test fail.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
I have a local test run where the sharp route-map usage
was being checked for 5 seconds. I saw usages going up
for each 1 second check and the 5th one was at 497 out
of 500. Looks like the system was really loaded. Let's
give it more time to coalesce under heavy load.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
Tests are removing core files and we are missing some
of them because of this.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
If a .dmp file is found in the test log directories
fail the test.
Issue: #13788
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
There are parts of our daemons that upon certain types
of errors that a zlog_backtrace is auto-generated.
It is desirable for this to be caught and have the
test auto-failed.
Issue: #13787
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
The total number of octets of the Sub-TLV Value field. The Sub-TLV Length field
contains 1 octet if the Sub-TLV Type field contains a value in the range from
0-127. The Sub-TLV Length field contains two octets if the Sub-TLV Type field
contains a value in the range from 128-255.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
The cli "show ip pim nexthop json" gives the RPF information.
However it doesn't give PIM enable status on the nexthop interface.
Added pimEnabled field in this clis,
this will tell if PIM is enabled or not on the nexthop interface.
Example:
frr# show ip pim nexthop
Number of registered addresses: 1
Address Interface Nexthop
108.0.0.2 ens224 108.0.0.2
frr# show ip pim nexthop json
{
"108.0.0.2":{
"address":"108.0.0.2",
"nexthops":[
{
"interface":"ens224",
"pimEnabled":true,
"nexthop":"108.0.0.2"
}
]
}
}
frr# configure terminal
frr(config)# int ens224
frr(config-if)# no ip pim
frr(config-if)# end
frr# show ip pim nexthop json
{
"108.0.0.2":{
"address":"108.0.0.2",
"nexthops":[
{
"interface":"ens224",
"pimEnabled":false,
"nexthop":"108.0.0.2"
}
]
}
}
Signed-off-by: Sarita Patra <saritap@vmware.com>
|
|
The mpls configuration does not work when an interface is
created after having applied the frr configuration. The
below scenario illustrates:
> root@dut:~# modprobe mpls
> root@dut:~# zebra &
> [..]
> dut(config)# interface ifacenotcreated
> dut(config-if)# mpls enable
> dut(config-if)# Ctrl-D
> root@dut:~# ip li show ifacenotcreated
> Device "ifacenotcreated" does not exist.
> root@dut:~# ip li add ifacenotcreated type dummy
> 0
Fix this by forcing the mpls flag when the interface is detected.
> root@dut:~# cat /proc/sys/net/mpls/conf/ifacenotcreat/input
> 1
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
|
|
OSPFv2 no area x stub no-summary only resets
'no-summary' config. From frr-reload if the config
line 'area x stub no-summary' is removed then
it needs to remove completely. Before this change
it took two frr-roload to remove the config which is
inconsistent behavior.
Fix is to frr-reload to add extra line to delete
'no area x stub'.
Ticket:#3514775
Testing Done:
Running config:
router ospf
ospf router-id 6.6.6.6
area 0.0.0.1 stub no-summary
area 0.0.0.2 stub
exit
!
router ospf vrf sym_1
area 0.0.1.1 range 24.1.1.0/24
area 0.0.1.2 stub no-summary
exit
changed frr.conf:
router ospf
ospf router-id 6.6.6.6
area 0.0.0.2 stub
exit
!
router ospf vrf sym_1
area 0.0.1.1 range 24.1.1.0/24
exit
Lines To Delete
===============
router ospf
no area 0.0.0.1 stub <<<< newly added
router ospf vrf sym_1
no area 0.0.1.2 stub <<<< newly added
router ospf
no area 0.0.0.1 stub no-summary
router ospf vrf sym_1
no area 0.0.1.2 stub no-summary
After fix new running-config post reload:
i
router ospf
ospf router-id 6.6.6.6
area 0.0.0.2 stub
exit
!
router ospf vrf sym_1
area 0.0.1.1 range 24.1.1.0/24
exit
Before fix running-config post 1st reload:
router ospf
ospf router-id 6.6.6.6
area 0.0.0.1 stub
area 0.0.0.2 stub
exit
!
router ospf vrf sym_1
area 0.0.1.1 range 24.1.1.0/24
area 0.0.1.2 stub
exit
Signed-off-by: Chirag Shah <chirag@nvidia.com>
|
|
This file is generated after `make check`.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
In scaled EVPN route sync from bgp to zebra, return
code can be ZCLIENT_SEND_BUFFERED which was treated
as error and leads to route install/uninstall failure.
Following error logs were seen:
2023-07-07T17:05:59.640899+03:00 vtep12 bgpd[15305]: [WYBZ0-MM8F1][EC
33554471] 0: Failed to uninstall EVPN IMET route in VNI 478
2023-07-07T17:05:59.640913+03:00 vtep12 bgpd[15305]: [Y5VKN-9BV7H][EC
33554471] default (0): Failed to uninstall EVPN [3]:[0]:[32]:[27.0.0.5]
route from VNI 465 IP table
2023-07-07T17:05:59.640927+03:00 vtep12 bgpd[15305]: [WYBZ0-MM8F1][EC
33554471] 0: Failed to uninstall EVPN IMET route in VNI 465
2023-07-07T17:05:59.640940+03:00 vtep12 bgpd[15305]: [Y5VKN-9BV7H][EC
33554471] default (0): Failed to uninstall EVPN [3]:[0]:[32]:[27.0.0.5]
route from VNI 173 IP table
Ticket:#3499957
Testing Done:
Before fix:
root@vtep12:mgmt:/home/cumulus# bridge -d -s fdb show | grep 27.0.0.5 |
wc -l
16010
Once source VTEP withdraws, DUT VTEP still has stale entries
root@vtep12:mgmt:~# bridge -d -s fdb show | grep 27.0.0.5 | wc -l
12990
After fix:
Once source VTEP withdraws, DUT VTEP still is able to delete entries
root@vtep12:mgmt:/home/cumulus# bridge -d -s fdb show | grep 27.0.0.5 |
wc -l
0
Zapi stats:
Client: bgp
[32/133]
------------------------
FD: 76
Connect Time: 00:26:17
Nexthop Registry Time: 00:26:11
Nexthop Last Update Time: 00:23:31
Client will Not be notified about it's routes status
Last Msg Rx Time: 00:21:33
Last Msg Tx Time: 00:23:31
Last Rcvd Cmd: ZEBRA_REMOTE_MACIP_ADD
Last Sent Cmd: ZEBRA_NEXTHOP_UPDATE
Type Add Update Del
==================================================
IPv4 7 0 1
IPv6 0 0 0
Redist:v4 22 0 0
Redist:v6 0 0 0
VRF 2 0 0
Connected 4170 0 0
Interface 9 0 4
Intf Addr 2166 0 0
BFD peer 0 0 0
NHT v4 2 0 1
NHT v6 4 0 0
VxLAN SG 0 0 0
VNI 1010 0 0
L3-VNI 0 0 0
MAC-IP 46010 0 0
ES 2024 0 0
ES-EVI 0 0 0
Errors: 0
Signed-off-by: Chirag Shah <chirag@nvidai.com>
|
|
https://www.rfc-editor.org/rfc/rfc8810.html
Not relevant anymore. Use RFC'd version of ORF.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
More details: https://www.rfc-editor.org/rfc/rfc8810.html
Not sure if we want to maintain the old code more.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
Already deprecated since two decades.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
When `dplane_fpm_nl` receives a route, it allocates memory for a dplane
context and calls `netlink_route_change_read_unicast_internal` without
initializing the `intf_extra_list` contained in the dplane context. If
`netlink_route_change_read_unicast_internal` is not able to process the
route, we call `dplane_ctx_fini` to free the dplane context. This causes
a crash because `dplane_ctx_fini` attempts to access the intf_extra_list
which is not initialized.
To solve this issue, we can call `dplane_ctx_route_init`to initialize
the dplane route context properly, just after the dplane context
allocation.
(gdb) bt
#0 0x0000555dd5ceae80 in dplane_intf_extra_list_pop (h=0x7fae1c007e68) at ../zebra/zebra_dplane.c:427
#1 dplane_ctx_free_internal (ctx=0x7fae1c0074b0) at ../zebra/zebra_dplane.c:724
#2 0x0000555dd5cebc99 in dplane_ctx_free (pctx=0x7fae2aa88c98) at ../zebra/zebra_dplane.c:869
#3 dplane_ctx_free (pctx=0x7fae2aa88c98, pctx@entry=0x7fae2aa78c28) at ../zebra/zebra_dplane.c:855
#4 dplane_ctx_fini (pctx=pctx@entry=0x7fae2aa88c98) at ../zebra/zebra_dplane.c:890
#5 0x00007fae31e93f29 in fpm_read (t=) at ../zebra/dplane_fpm_nl.c:605
#6 0x00007fae325191dd in thread_call (thread=thread@entry=0x7fae2aa98da0) at ../lib/thread.c:2006
#7 0x00007fae324c42b8 in fpt_run (arg=0x555dd74777c0) at ../lib/frr_pthread.c:309
#8 0x00007fae32405ea7 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#9 0x00007fae32325a2f in clone () from /lib/x86_64-linux-gnu/libc.so.6
Fixes: #13754
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
|
|
The function `dplane_ctx_route_init` initializes a dplane route context
from the route object passed as an argument. Let's abstract this
function to allow initializing the dplane route context without actually
copying a route object.
This allows us to use this function for initializing a dplane route
context when we don't have any route to copy in it.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
|
|
In the function ospf_lsa_translated_nssa_new the newly created lsa is lock however, the return lsa from ospf_lsa_new already has a lock. Therefore removing the addition lock resolve the leak below.
ospf_basic_functionality.test_ospf_nssa#r3.asan.ospfd.5456
=================================================================
==5456==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 640 byte(s) in 5 object(s) allocated from:
#0 0x7f294f354a37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7f294eeed562 in qcalloc ../lib/memory.c:105
#2 0x561a16004f60 in ospf_lsa_new ../ospfd/ospf_lsa.c:186
#3 0x561a160051a1 in ospf_lsa_new_and_data ../ospfd/ospf_lsa.c:205
#4 0x561a1600f21d in ospf_exnl_lsa_prepare_and_flood ../ospfd/ospf_lsa.c:1762
#5 0x561a1600fd71 in ospf_external_lsa_new ../ospfd/ospf_lsa.c:1863
#6 0x561a160107d7 in ospf_lsa_translated_nssa_new ../ospfd/ospf_lsa.c:1985
#7 0x561a16011cfb in ospf_translated_nssa_refresh ../ospfd/ospf_lsa.c:2152
#8 0x561a16014bb2 in ospf_external_lsa_install ../ospfd/ospf_lsa.c:2871
#9 0x561a1601596b in ospf_lsa_install ../ospfd/ospf_lsa.c:3076
#10 0x561a16168b3c in ospf_flood ../ospfd/ospf_flood.c:482
#11 0x561a160462f8 in ospf_ls_upd ../ospfd/ospf_packet.c:2115
#12 0x561a1604c66c in ospf_read_helper ../ospfd/ospf_packet.c:3198
#13 0x561a1604c88e in ospf_read ../ospfd/ospf_packet.c:3229
#14 0x7f294efd6c33 in event_call ../lib/event.c:1995
#15 0x7f294eec134a in frr_run ../lib/libfrr.c:1213
#16 0x561a15fd3b6d in main ../ospfd/ospf_main.c:249
#17 0x7f294e998d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Objects leaked above:
0x60c000062800 (128 bytes)
0x60c000062c80 (128 bytes)
0x60c0000631c0 (128 bytes)
0x60c000063700 (128 bytes)
0x60c000063d00 (128 bytes)
Direct leak of 640 byte(s) in 5 object(s) allocated from:
#0 0x7f294f354a37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7f294eeed562 in qcalloc ../lib/memory.c:105
#2 0x561a16004f60 in ospf_lsa_new ../ospfd/ospf_lsa.c:186
#3 0x561a160051a1 in ospf_lsa_new_and_data ../ospfd/ospf_lsa.c:205
#4 0x561a1600f21d in ospf_exnl_lsa_prepare_and_flood ../ospfd/ospf_lsa.c:1762
#5 0x561a1600fd71 in ospf_external_lsa_new ../ospfd/ospf_lsa.c:1863
#6 0x561a160107d7 in ospf_lsa_translated_nssa_new ../ospfd/ospf_lsa.c:1985
#7 0x561a16010e10 in ospf_translated_nssa_originate ../ospfd/ospf_lsa.c:2034
#8 0x561a16136559 in ospf_abr_translate_nssa ../ospfd/ospf_abr.c:668
#9 0x561a161383da in ospf_abr_process_nssa_translates ../ospfd/ospf_abr.c:968
#10 0x561a1613f9b8 in ospf_abr_nssa_task ../ospfd/ospf_abr.c:2054
#11 0x561a161402e5 in ospf_abr_task_timer ../ospfd/ospf_abr.c:2168
#12 0x7f294efd6c33 in event_call ../lib/event.c:1995
#13 0x7f294eec134a in frr_run ../lib/libfrr.c:1213
#14 0x561a15fd3b6d in main ../ospfd/ospf_main.c:249
#15 0x7f294e998d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Objects leaked above:
0x60c00003e380 (128 bytes)
0x60c00003e740 (128 bytes)
0x60c00003eb00 (128 bytes)
0x60c00005fd40 (128 bytes)
0x60c00005ff80 (128 bytes)
Indirect leak of 180 byte(s) in 5 object(s) allocated from:
#0 0x7f294f354a37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7f294eeed562 in qcalloc ../lib/memory.c:105
#2 0x561a16005a43 in ospf_lsa_data_new ../ospfd/ospf_lsa.c:296
#3 0x561a160051b1 in ospf_lsa_new_and_data ../ospfd/ospf_lsa.c:206
#4 0x561a1600f21d in ospf_exnl_lsa_prepare_and_flood ../ospfd/ospf_lsa.c:1762
#5 0x561a1600fd71 in ospf_external_lsa_new ../ospfd/ospf_lsa.c:1863
#6 0x561a160107d7 in ospf_lsa_translated_nssa_new ../ospfd/ospf_lsa.c:1985
#7 0x561a16011cfb in ospf_translated_nssa_refresh ../ospfd/ospf_lsa.c:2152
#8 0x561a16014bb2 in ospf_external_lsa_install ../ospfd/ospf_lsa.c:2871
#9 0x561a1601596b in ospf_lsa_install ../ospfd/ospf_lsa.c:3076
#10 0x561a16168b3c in ospf_flood ../ospfd/ospf_flood.c:482
#11 0x561a160462f8 in ospf_ls_upd ../ospfd/ospf_packet.c:2115
#12 0x561a1604c66c in ospf_read_helper ../ospfd/ospf_packet.c:3198
#13 0x561a1604c88e in ospf_read ../ospfd/ospf_packet.c:3229
#14 0x7f294efd6c33 in event_call ../lib/event.c:1995
#15 0x7f294eec134a in frr_run ../lib/libfrr.c:1213
#16 0x561a15fd3b6d in main ../ospfd/ospf_main.c:249
#17 0x7f294e998d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Objects leaked above:
0x60400003f890 (36 bytes)
0x60400003f990 (36 bytes)
0x60400003fa50 (36 bytes)
0x60400003fb10 (36 bytes)
0x60400003fbd0 (36 bytes)
Indirect leak of 180 byte(s) in 5 object(s) allocated from:
#0 0x7f294f354a37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x7f294eeed562 in qcalloc ../lib/memory.c:105
#2 0x561a16005a43 in ospf_lsa_data_new ../ospfd/ospf_lsa.c:296
#3 0x561a160051b1 in ospf_lsa_new_and_data ../ospfd/ospf_lsa.c:206
#4 0x561a1600f21d in ospf_exnl_lsa_prepare_and_flood ../ospfd/ospf_lsa.c:1762
#5 0x561a1600fd71 in ospf_external_lsa_new ../ospfd/ospf_lsa.c:1863
#6 0x561a160107d7 in ospf_lsa_translated_nssa_new ../ospfd/ospf_lsa.c:1985
#7 0x561a16010e10 in ospf_translated_nssa_originate ../ospfd/ospf_lsa.c:2034
#8 0x561a16136559 in ospf_abr_translate_nssa ../ospfd/ospf_abr.c:668
#9 0x561a161383da in ospf_abr_process_nssa_translates ../ospfd/ospf_abr.c:968
#10 0x561a1613f9b8 in ospf_abr_nssa_task ../ospfd/ospf_abr.c:2054
#11 0x561a161402e5 in ospf_abr_task_timer ../ospfd/ospf_abr.c:2168
#12 0x7f294efd6c33 in event_call ../lib/event.c:1995
#13 0x7f294eec134a in frr_run ../lib/libfrr.c:1213
#14 0x561a15fd3b6d in main ../ospfd/ospf_main.c:249
#15 0x7f294e998d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Objects leaked above:
0x60400003c6d0 (36 bytes)
0x60400003c790 (36 bytes)
0x60400003c810 (36 bytes)
0x60400003c890 (36 bytes)
0x60400003c910 (36 bytes)
SUMMARY: AddressSanitizer: 1640 byte(s) leaked in 20 allocation(s).
Signed-off-by: ryndia <dindyalsarvesh@gmail.com>
|
