Description:
ospf process is crashing when the current router acts
as GR helper and it received a new lsa.
Here, ospf_lsa_different() is being called without checking
'old' pointer. It is asserted in ospf_lsa_different() api
if the 'old' pointer is NULL.
corrected this by validaing old pointer before calling
ospf_lsa_different() api.
back tarce:
Program terminated with signal SIGABRT, Aborted.
0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
[Current thread is 1 (Thread 0x6b84348827c0 (LWP 3155))]
0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
1 0x00006b8433aa4801 in __GI_abort () at abort.c:79
2 0x00006b8433a9439a in __assert_fail_base (fmt=0x6b8433c1b7d8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x162ffc0630bc "l1", file=file@entry=0x162ffc062ff7 "ospfd/ospf_lsa.c", line=line@entry=3520, function=function@entry=0x162ffc0646f0 <__PRETTY_FUNCTION__.18732> "ospf_lsa_different") at assert.c:92
3 0x00006b8433a94412 in __GI___assert_fail (assertion=assertion@entry=0x162ffc0630bc "l1", file=file@entry=0x162ffc062ff7 "ospfd/ospf_lsa.c", line=line@entry=3520, function=function@entry=0x162ffc0646f0 <__PRETTY_FUNCTION__.18732> "ospf_lsa_different") at assert.c:101
4 0x0000162ffc008c25 in ospf_lsa_different (l1=l1@entry=0x0, l2=l2@entry=0x162ffe535c60, ignore_rcvd_flag=ignore_rcvd_flag@entry=true) at ospfd/ospf_lsa.c:3520
5 0x0000162ffc00a8e8 in ospf_lsa_install (ospf=ospf@entry=0x162ffe513650, oi=oi@entry=0x162ffe531c30, lsa=lsa@entry=0x162ffe535c60) at ospfd/ospf_lsa.c:2892
6 0x0000162ffc059d16 in ospf_flood (ospf=0x162ffe513650, nbr=nbr@entry=0x162ffe52cc90, current=current@entry=0x0, new=new@entry=0x162ffe535c60) at ospfd/ospf_flood.c:429
7 0x0000162ffc01838f in ospf_ls_upd (size=<optimized out>, oi=0x162ffe531c30, s=<optimized out>, ospfh=<optimized out>, iph=<optimized out>, ospf=<optimized out>) at ospfd/ospf_packet.c:2162
8 ospf_read_helper (ospf=<optimized out>) at ospfd/ospf_packet.c:3241
9 ospf_read (thread=<optimized out>) at ospfd/ospf_packet.c:3272
10 0x00006b843450139c in thread_call (thread=thread@entry=0x7780f42c7480) at lib/thread.c:1692
11 0x00006b84344cfb18 in frr_run (master=0x162ffe34d130) at lib/libfrr.c:1068
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
Modifying igmp_group_count of struct pim_instance
to gm_group_count which is to be used for both IGMP and MLD.
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
Before:
```
$ vtysh -c 'show bgp l2vpn evpn route detail json'
<<<<<<<<<<<<<<<<<<<< empty line
<<<<<<<<<<<<<<<<<<<< empty line
<<<<<<<<<<<<<<<<<<<< empty line
<<<<<<<<<<<<<<<<<<<< empty line
{
...
"numPrefix":4,
"numPaths":4 <<<<< four paths = four empty lines
}
```
Contain as much "empty lines" before the JSON string as the number
of paths displayed.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When calling time(NULL), FRR is intentionally throwing
away the upper 32 bits of value returned. Let's explicitly
call it out so that coverity understands this is intentional
and ok.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Let's convert to our actual library call instead
of using yet another abstraction that makes it fun
for people to switch daemons.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Running the `zebra_seg6local_route` topotest with `--valgrind-memleaks`
gives several memory leak errors. This is due to the way SRv6 routes
(seg6 and seg6local routes) are handled: when the user executes the CLI
command `sharp install seg6-routes` or `sharp install seg6local-routes`
to create a seg6 or seg6local route, sharpd calls
`nexthop_add_srv6_seg6` or `nexthop_add_srv6_seg6local` to create an
SRv6 nexthop. A pointer to the SRv6 nexthop is stored in the global data
structure `sg.r.nhop`. If you call `sharp install routes`,
`sharp install seg6-routes` or `sharp install seg6local-routes` to create
more routes, `sg.r.nhop` is set to zero and the
pointer to the SRv6 nexthop contained in `sg.r.nhop` is definitely lost
and the allocated memory is never freed.
This patch adds calls to `nexthop_del_srv6_seg6()` and
`nexthop_del_srv6_seg6local()` to free the memory allocated for the SRv6
nexthop before clearing the `sg.r.nhop` data structure.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
Running the `zebra_seg6local_route` topotest with `--valgrind-memleaks`
gives several memory leak errors. This is due to the way SRv6 chunks are
released: when the user executes the CLI command
`sharp srv6-manager release-locator-chunk` to release the chunks of an
SRv6 locator, the `list_delete()` function is called to delete the
chunks list (`loc->chunks`), but the memory allocated for the chunks is
not freed.
This patch defines a new callback `sharp_srv6_locator_chunk_free()`.
This callback takes care of freeing the memory allocated for a given
chunk. When `list_delete()` is called to remove the chunk list
`loc->chunks`, it automatically calls `sharp_srv6_locator_chunk_free()`
on each element of the list to free the allocated memory before
deleting the list.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
Running the `zebra_seg6local_route` topotest with `--valgrind-memleaks`
gives several memory leak errors. This is due to the way SRv6 chunks are
released: when the user executes the CLI command
`sharp srv6-manager release-locator-chunk` to release the chunks of an
SRv6 locator, all the chunks are removed from the list `loc->chunks`.
Also, the locator is removed from the SRv6 locators list
`sg.srv6_locators`, but the memory allocated for the locator is not
freed.
This patch adds a call to `XFREE()` to properly free the allocated
memory when all the chunks of an SRv6 locator are removed and the
locator is removed as well.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
