cro to test
> this theory?
>
>
>
> /neale
>
>
>
>
>
> *From: *Stanislav Zaikin
> *Date: *Friday, 22 October 2021 at 15:06
> *To: *Neale Ranns
> *Cc: *vpp-dev
> *Subject: *Re: [vpp-dev] assert in pool_elt_at_index
>
> Hi Neale,
>
>
>
> Sure
have a reliable reproduction environment, could you
cook your own pool_put_would_expand macro to test this theory?
/neale
From: Stanislav Zaikin
Date: Friday, 22 October 2021 at 15:06
To: Neale Ranns
Cc: vpp-dev
Subject: Re: [vpp-dev] assert in pool_elt_at_index
Hi Neale,
Sure, here it is
s are doing.
>
>
>
> /neale
>
>
>
> *From: *vpp-dev@lists.fd.io on behalf of Stanislav
> Zaikin via lists.fd.io
> *Date: *Wednesday, 13 October 2021 at 20:30
> *To: *vpp-dev
> *Subject: *[vpp-dev] assert in pool_elt_at_index
>
> Hello folks,
>
>
&g
Hi Stanislav,
Can you do:
thread apply all bt
I’d like to see what the other threads are doing.
/neale
From: vpp-dev@lists.fd.io on behalf of Stanislav Zaikin
via lists.fd.io
Date: Wednesday, 13 October 2021 at 20:30
To: vpp-dev
Subject: [vpp-dev] assert in pool_elt_at_index
Hello folks
d the relevant fix. If not, ASan
should work on master.
Best
ben
> -Original Message-
> From: Stanislav Zaikin
> Sent: jeudi 21 octobre 2021 19:26
> To: Benoit Ganne (bganne)
> Cc: vpp-dev
> Subject: Re: [vpp-dev] assert in pool_elt_at_index
>
> Hi Benoit,
&g
ch the corruption earlier with more clues.
>
> Best
> ben
>
> > -Original Message-
> > From: vpp-dev@lists.fd.io On Behalf Of Stanislav
> > Zaikin
> > Sent: vendredi 15 octobre 2021 14:54
> > To: vpp-dev
> > Subject: Re: [vpp-dev] assert in
i 15 octobre 2021 14:54
> To: vpp-dev
> Subject: Re: [vpp-dev] assert in pool_elt_at_index
>
> Any thoughts will be much appreciated. This bug is quite reproducible in
> my environment, but I don't know what else to check.
>
>
> On Thu, 14 Oct 2021 at 08:51,
Any thoughts will be much appreciated. This bug is quite reproducible in my
environment, but I don't know what else to check.
On Thu, 14 Oct 2021 at 08:51, Stanislav Zaikin via lists.fd.io wrote:
> Hi Florin,
> Hi Rajith,
>
> It shouldn't be the pool expansion case, I have
> 8341f76fd1cd4351961c
Hi Florin,
Hi Rajith,
It shouldn't be the pool expansion case, I have
8341f76fd1cd4351961cd8161cfed2814fc55103.
Moreover, in this case _e would be different from
&load_balance_pool[3604]. I've
found some of those expansions (in other places), in those cases a pointer
to the element has a different
HI Stanislav,
My guess is you don't have the commit below.
commit 8341f76fd1cd4351961cd8161cfed2814fc55103
Author: Dave Barach
Date: Wed Jun 3 08:05:15 2020 -0400
fib: add barrier sync, pool/vector expand cases
load_balance_alloc_i(...) is not thread safe when the
load_balance_po
Hi Stanislav,
The only thing I can think of is that main thread grows the pool, or the pool’s
bitmap, without a worker barrier while the worker that asserts is trying to
access it. Is main thread busy doing something (e.g., adding routes/interfaces)
when the assert happens?
Regards,
Florin
Hi Florin,
I wasn't aware of those helper functions, thanks! But yeah, it also returns
0 (sorry, but there's the trace of another crash)
Thread 3 "vpp_wk_0" received signal SIGABRT, Aborted.
[Switching to Thread 0x7f9cc0f6a700 (LWP 3546)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux
Hi Stanislav,
Just to make sure the gdb macro is okay, could you run from gdb: pifi(pool,
index)? The function is defined in gdb_funcs.c.
Regards,
Florin
> On Oct 13, 2021, at 11:30 AM, Stanislav Zaikin wrote:
>
> Hello folks,
>
> I'm facing a strange issue with 2 worker threads. Sometimes
Hello folks,
I'm facing a strange issue with 2 worker threads. Sometimes I get a crash
either in "ip6-lookup" or "mpls-lookup" nodes. They happen with assert in
the *pool_elt_at_index* macro and always inside the "*load_balance_get*"
function. But the load_balance dpo looks perfectly good, I mean
14 matches
Mail list logo
