d from *pool_elt_at_index *as the index is
>>> already freed.
>>>
>>> Is it not possible that the main thread freed the pool entry, while the
>>> worker thread was holding an index. The backtraces I have attached indicate
>>> that the main thread was fr
freeing fib entries.
>>
>> Thanks,
>> Rajith
>>
>>
>> On Tue, Jul 7, 2020 at 5:50 PM Benoit Ganne (bganne)
>> wrote:
>>
>>> Hi Rajith,
>>>
>>> You are probably missing https://gerrit.fd.io/r/c/vpp/+/27407
>>> https:/
tps://gerrit.fd.io/r/c/vpp/+/27407
>> https://gerrit.fd.io/r/c/vpp/+/27454 and maybe
>> https://gerrit.fd.io/r/c/vpp/+/27448
>>
>> Best
>> ben
>>
>> > -Original Message-
>> > From: vpp-dev@lists.fd.io On Behalf Of Rajith PR
>
al Message-
> > From: vpp-dev@lists.fd.io On Behalf Of Rajith PR
> via
> > lists.fd.io
> > Sent: mardi 7 juillet 2020 14:11
> > To: vpp-dev
> > Subject: [vpp-dev]: ASSERT in load_balance_get()
> >
> > Hi All,
> >
> > During our scale testing of
juillet 2020 14:11
> To: vpp-dev
> Subject: [vpp-dev]: ASSERT in load_balance_get()
>
> Hi All,
>
> During our scale testing of routes we have hit an ASSERT in
> load_balance_get() . From the code it looks like the lb_index(148)
> referred to is already returned to the
Hi All,
During our scale testing of routes we have hit an ASSERT in *load_balance_get()
. * From the code it looks like the lb_index(148) referred to is already
returned to the pool by the main thread causing the ASSERT in the worker.
The version in *19.08. *We have two workers and a main thread.
Hi All,
During our scale testing of routes we have hit an ASSERT in *load_balance_get()
. * From the code it looks like the lb_index(148) referred to is already
returned to the pool by the main thread causing the ASSERT in the worker.
The version in *19.08. *We have two workers and a main thread.