vrouter core filre created

[dshimo]

<--- Contrail Version
Version: 2.20-64
Op Sys: Ubuntu 14.04
OS: Juno

Vrouter core file was created in customer contrail/openstack system.
It's 4 times = 4 core file created.
I attached the all core files.

Please investigate the root cause.

Thanks,

[dshimo (dshimo)]

I attached the core files.

[Hari Prasad Killi (haripk)]

(gdb) bt
#0 0x00007faf8aa61cc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007faf8aa650d8 in __GI_abort () at abort.c:89
#2 0x00007faf8aa5ab86 in __assert_fail_base (fmt=0x7faf8abab830 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0xfdee15 "0",
    file=file@entry=0xfed0e0 "controller/src/vnsw/agent/oper/vrf.cc", line=line@entry=318,
    function=function@entry=0xfed2a0 <VrfEntry::DeleteTimeout()::__PRETTY_FUNCTION__> "bool VrfEntry::DeleteTimeout()") at assert.c:92
#3 0x00007faf8aa5ac32 in __GI___assert_fail (assertion=0xfdee15 "0", file=0xfed0e0 "controller/src/vnsw/agent/oper/vrf.cc", line=318,
    function=0xfed2a0 <VrfEntry::DeleteTimeout()::__PRETTY_FUNCTION__> "bool VrfEntry::DeleteTimeout()") at assert.c:101
#4 0x00000000009cd87d in VrfEntry::DeleteTimeout (this=<optimized out>) at controller/src/vnsw/agent/oper/vrf.cc:318
#5 0x0000000000fa9529 in operator() (this=<optimized out>) at /usr/include/boost/function/function_template.hpp:767
#6 Timer::TimerTask::Run (this=0x19d9260) at controller/src/base/timer.cc:42
#7 0x0000000000fa2f20 in TaskImpl::execute (this=0x7faf842c1a40) at controller/src/base/task.cc:238

[Manish Singh (manishs)]

there was a similar issue seen in https://bugs.launchpad.net/juniperopenstack/+bug/1452362/comments/2
It has been fixed with latest builds of R2.20

[dshimo (dshimo)]

Customer using the contrail version 2.20-64.
However, core dump was created. Which version is it fixed in?

[Hari Prasad Killi (haripk)]

Fix is available in build 95.

[dshimo (dshimo)]

> Fix is available in build 95.
Thanks for this information.
When is it available (release)?

And I have an one question. Actually, I don't clear understanding regarding root cause for this issue.
If possible, would you please provide more detail for root cause and why this issue happened?

[Ashish Ranjan (aranjan-n)]

The fix will be part of 2.21 release in mid sept. The code commit has detailed explanation off the fix. Pl follow the original bug.

[dshimo (dshimo)]

Thanks for analysis link. I did check it.

Our customer setup is Left-VN = L3VPN (l3/l2 VN) and Right-VN = EVPN (L2 only VN).
How can i reproduce this issue in EVPN setup?