Closed
Conversation
swssconfig/swssconfig.cpp
Outdated
| using json = nlohmann::json; | ||
|
|
||
| int db_port = 6379; | ||
| const char* const hostname = "localhost"; |
Contributor
There was a problem hiding this comment.
Please read those values from command line (with defaults as defines)
Author
There was a problem hiding this comment.
This behavior is based on neighsyncd as a sample. Most of apps use hardcoded port and host name.
If we decide to change all of them it can be done in one changelist.
swssconfig/swssconfig.cpp
Outdated
|
|
||
| int main(int argc, char **argv) | ||
| { | ||
| Logger::setMinPrio(Logger::SWSS_DEBUG); |
Contributor
There was a problem hiding this comment.
do we need to set to DEBUG?
hrachya-m
pushed a commit
to hrachya-m/sonic-swss
that referenced
this pull request
Apr 4, 2016
* replaced tabs with spaces * change type& var, to type &var * change to conditional build on swssconfig if json.hpp is present - eliminates need of 3rd party license.
hrachya-m
pushed a commit
to hrachya-m/sonic-swss
that referenced
this pull request
Apr 5, 2016
* replaced tabs with spaces * change type& var, to type &var * change to conditional build on swssconfig if json.hpp is present - eliminates need of 3rd party license.
added 2 commits
April 4, 2016 17:18
…file * Adding application which loads db settings from json file * Modified configure.ac and Makefile to include swssconfig into build. Signed-off-by: Hrachya Mughnetsyan [email protected]
* replaced tabs with spaces * change type& var, to type &var * change to conditional build on swssconfig if json.hpp is present - eliminates need of 3rd party license.
* dropped fpm-like approach of build process. Changed build of swssconfig to use local copy of json.hpp
|
|
||
| using namespace std; | ||
| using namespace swss; | ||
| using json = nlohmann::json; |
Contributor
There was a problem hiding this comment.
Please don't use "using namespace", please use full namespace like "std::string" instead of "string" this will avoid making conflicts with same name in multiple namespaces
Contributor
There was a problem hiding this comment.
It's source file (CPP) and not include, it shouldn't cause conflicts. I think it's okay.
* added sample json input file for swssconfig. Signed-off-by: Hrachya Mughnetsyan [email protected]
Contributor
|
acked by Shuotian Cheng |
vharish02
pushed a commit
to vharish02/sonic-swss
that referenced
this pull request
Aug 6, 2018
* Create sonic-features.md * Updating with NAS and PAS contribution
ishidawataru
pushed a commit
to ishidawataru/sonic-swss
that referenced
this pull request
Aug 29, 2018
vasant17
added a commit
to vasant17/sonic-swss
that referenced
this pull request
Nov 22, 2019
* DPB ACL dependency implemenatation and test cases * Code-review comments addressed * ACL empty port list support, Codereview comments, and Bug fixes
vasant17
added a commit
to vasant17/sonic-swss
that referenced
this pull request
Dec 13, 2019
vasant17
added a commit
to vasant17/sonic-swss
that referenced
this pull request
Feb 2, 2020
vasant17
added a commit
to vasant17/sonic-swss
that referenced
this pull request
Feb 11, 2020
vasant17
added a commit
to vasant17/sonic-swss
that referenced
this pull request
Mar 6, 2020
oleksandrivantsiv
pushed a commit
to oleksandrivantsiv/sonic-swss
that referenced
this pull request
Mar 1, 2023
lukasstockner
pushed a commit
to genesiscloud/sonic-swss
that referenced
this pull request
Apr 2, 2023
qiluo-msft
pushed a commit
that referenced
this pull request
Aug 7, 2023
**What I did**
Fix the Mem Leak by moving the raw pointers in type_maps to use smart pointers
**Why I did it**
```
Indirect leak of 83776 byte(s) in 476 object(s) allocated from:
#0 0x7f0a2a414647 in operator new(unsigned long) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:99
#1 0x5555590cc923 in __gnu_cxx::new_allocator, std::allocator > const, referenced_object> > >::allocate(unsigned long, void const*) /usr/include/c++/10/ext/new_allocator.h:115
#2 0x5555590cc923 in std::allocator_traits, std::allocator > const, referenced_object> > > >::allocate(std::allocator, std::allocator > const, referenced_object> > >&, unsigned long) /usr/include/c++/10/bits/alloc_traits.h:460
#3 0x5555590cc923 in std::_Rb_tree, std::allocator >, std::pair, std::allocator > const, referenced_object>, std::_Select1st, std::allocator > const, referenced_object> >, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::_M_get_node() /usr/include/c++/10/bits/stl_tree.h:584
#4 0x5555590cc923 in std::_Rb_tree_node, std::allocator > const, referenced_object> >* std::_Rb_tree, std::allocator >, std::pair, std::allocator > const, referenced_object>, std::_Select1st, std::allocator > const, referenced_object> >, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::_M_create_node, std::allocator > const&>, std::tuple<> >(std::piecewise_construct_t const&, std::tuple, std::allocator > const&>&&, std::tuple<>&&) /usr/include/c++/10/bits/stl_tree.h:634
#5 0x5555590cc923 in std::_Rb_tree_iterator, std::allocator > const, referenced_object> > std::_Rb_tree, std::allocator >, std::pair, std::allocator > const, referenced_object>, std::_Select1st, std::allocator > const, referenced_object> >, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::_M_emplace_hint_unique, std::allocator > const&>, std::tuple<> >(std::_Rb_tree_const_iterator, std::allocator > const, referenced_object> >, std::piecewise_construct_t const&, std::tuple, std::allocator > const&>&&, std::tuple<>&&) /usr/include/c++/10/bits/stl_tree.h:2461
#6 0x5555590e8757 in std::map, std::allocator >, referenced_object, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::operator[](std::__cxx11::basic_string, std::allocator > const&) /usr/include/c++/10/bits/stl_map.h:501
#7 0x5555590d48b0 in Orch::setObjectReference(std::map, std::allocator >, std::map, std::allocator >, referenced_object, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >*, std::less, std::allocator > >, std::allocator, std::allocator > const, std::map, std::allocator >, referenced_object, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >*> > >&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&) orchagent/orch.cpp:450
#8 0x5555594ff66b in QosOrch::handleQueueTable(Consumer&, std::tuple, std::allocator >, std::__cxx11::basic_string, std::allocator >, std::vector, std::allocator >, std::__cxx11::basic_string, std::allocator > >, std::allocator, std::allocator >, std::__cxx11::basic_string, std::allocator > > > > >&) orchagent/qosorch.cpp:1763
#9 0x5555594edbd6 in QosOrch::doTask(Consumer&) orchagent/qosorch.cpp:2179
#10 0x5555590c8743 in Consumer::drain() orchagent/orch.cpp:241
#11 0x5555590c8743 in Consumer::drain() orchagent/orch.cpp:238
#12 0x5555590c8743 in Consumer::execute() orchagent/orch.cpp:235
#13 0x555559090dad in OrchDaemon::start() orchagent/orchdaemon.cpp:755
#14 0x555558e9be25 in main orchagent/main.cpp:766
#15 0x7f0a299b6d09 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x23d09)
```
StormLiangMS
pushed a commit
that referenced
this pull request
Aug 14, 2023
**What I did**
Fix the Mem Leak by moving the raw pointers in type_maps to use smart pointers
**Why I did it**
```
Indirect leak of 83776 byte(s) in 476 object(s) allocated from:
#0 0x7f0a2a414647 in operator new(unsigned long) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:99
#1 0x5555590cc923 in __gnu_cxx::new_allocator, std::allocator > const, referenced_object> > >::allocate(unsigned long, void const*) /usr/include/c++/10/ext/new_allocator.h:115
#2 0x5555590cc923 in std::allocator_traits, std::allocator > const, referenced_object> > > >::allocate(std::allocator, std::allocator > const, referenced_object> > >&, unsigned long) /usr/include/c++/10/bits/alloc_traits.h:460
#3 0x5555590cc923 in std::_Rb_tree, std::allocator >, std::pair, std::allocator > const, referenced_object>, std::_Select1st, std::allocator > const, referenced_object> >, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::_M_get_node() /usr/include/c++/10/bits/stl_tree.h:584
#4 0x5555590cc923 in std::_Rb_tree_node, std::allocator > const, referenced_object> >* std::_Rb_tree, std::allocator >, std::pair, std::allocator > const, referenced_object>, std::_Select1st, std::allocator > const, referenced_object> >, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::_M_create_node, std::allocator > const&>, std::tuple<> >(std::piecewise_construct_t const&, std::tuple, std::allocator > const&>&&, std::tuple<>&&) /usr/include/c++/10/bits/stl_tree.h:634
#5 0x5555590cc923 in std::_Rb_tree_iterator, std::allocator > const, referenced_object> > std::_Rb_tree, std::allocator >, std::pair, std::allocator > const, referenced_object>, std::_Select1st, std::allocator > const, referenced_object> >, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::_M_emplace_hint_unique, std::allocator > const&>, std::tuple<> >(std::_Rb_tree_const_iterator, std::allocator > const, referenced_object> >, std::piecewise_construct_t const&, std::tuple, std::allocator > const&>&&, std::tuple<>&&) /usr/include/c++/10/bits/stl_tree.h:2461
#6 0x5555590e8757 in std::map, std::allocator >, referenced_object, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::operator[](std::__cxx11::basic_string, std::allocator > const&) /usr/include/c++/10/bits/stl_map.h:501
#7 0x5555590d48b0 in Orch::setObjectReference(std::map, std::allocator >, std::map, std::allocator >, referenced_object, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >*, std::less, std::allocator > >, std::allocator, std::allocator > const, std::map, std::allocator >, referenced_object, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >*> > >&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&) orchagent/orch.cpp:450
#8 0x5555594ff66b in QosOrch::handleQueueTable(Consumer&, std::tuple, std::allocator >, std::__cxx11::basic_string, std::allocator >, std::vector, std::allocator >, std::__cxx11::basic_string, std::allocator > >, std::allocator, std::allocator >, std::__cxx11::basic_string, std::allocator > > > > >&) orchagent/qosorch.cpp:1763
#9 0x5555594edbd6 in QosOrch::doTask(Consumer&) orchagent/qosorch.cpp:2179
#10 0x5555590c8743 in Consumer::drain() orchagent/orch.cpp:241
#11 0x5555590c8743 in Consumer::drain() orchagent/orch.cpp:238
#12 0x5555590c8743 in Consumer::execute() orchagent/orch.cpp:235
#13 0x555559090dad in OrchDaemon::start() orchagent/orchdaemon.cpp:755
#14 0x555558e9be25 in main orchagent/main.cpp:766
#15 0x7f0a299b6d09 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x23d09)
```
StormLiangMS
pushed a commit
that referenced
this pull request
Aug 14, 2023
**What I did**
Fix the Mem Leak by moving the raw pointers in type_maps to use smart pointers
**Why I did it**
```
Indirect leak of 83776 byte(s) in 476 object(s) allocated from:
#0 0x7f0a2a414647 in operator new(unsigned long) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:99
#1 0x5555590cc923 in __gnu_cxx::new_allocator, std::allocator > const, referenced_object> > >::allocate(unsigned long, void const*) /usr/include/c++/10/ext/new_allocator.h:115
#2 0x5555590cc923 in std::allocator_traits, std::allocator > const, referenced_object> > > >::allocate(std::allocator, std::allocator > const, referenced_object> > >&, unsigned long) /usr/include/c++/10/bits/alloc_traits.h:460
#3 0x5555590cc923 in std::_Rb_tree, std::allocator >, std::pair, std::allocator > const, referenced_object>, std::_Select1st, std::allocator > const, referenced_object> >, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::_M_get_node() /usr/include/c++/10/bits/stl_tree.h:584
#4 0x5555590cc923 in std::_Rb_tree_node, std::allocator > const, referenced_object> >* std::_Rb_tree, std::allocator >, std::pair, std::allocator > const, referenced_object>, std::_Select1st, std::allocator > const, referenced_object> >, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::_M_create_node, std::allocator > const&>, std::tuple<> >(std::piecewise_construct_t const&, std::tuple, std::allocator > const&>&&, std::tuple<>&&) /usr/include/c++/10/bits/stl_tree.h:634
#5 0x5555590cc923 in std::_Rb_tree_iterator, std::allocator > const, referenced_object> > std::_Rb_tree, std::allocator >, std::pair, std::allocator > const, referenced_object>, std::_Select1st, std::allocator > const, referenced_object> >, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::_M_emplace_hint_unique, std::allocator > const&>, std::tuple<> >(std::_Rb_tree_const_iterator, std::allocator > const, referenced_object> >, std::piecewise_construct_t const&, std::tuple, std::allocator > const&>&&, std::tuple<>&&) /usr/include/c++/10/bits/stl_tree.h:2461
#6 0x5555590e8757 in std::map, std::allocator >, referenced_object, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::operator[](std::__cxx11::basic_string, std::allocator > const&) /usr/include/c++/10/bits/stl_map.h:501
#7 0x5555590d48b0 in Orch::setObjectReference(std::map, std::allocator >, std::map, std::allocator >, referenced_object, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >*, std::less, std::allocator > >, std::allocator, std::allocator > const, std::map, std::allocator >, referenced_object, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >*> > >&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&) orchagent/orch.cpp:450
#8 0x5555594ff66b in QosOrch::handleQueueTable(Consumer&, std::tuple, std::allocator >, std::__cxx11::basic_string, std::allocator >, std::vector, std::allocator >, std::__cxx11::basic_string, std::allocator > >, std::allocator, std::allocator >, std::__cxx11::basic_string, std::allocator > > > > >&) orchagent/qosorch.cpp:1763
#9 0x5555594edbd6 in QosOrch::doTask(Consumer&) orchagent/qosorch.cpp:2179
#10 0x5555590c8743 in Consumer::drain() orchagent/orch.cpp:241
#11 0x5555590c8743 in Consumer::drain() orchagent/orch.cpp:238
#12 0x5555590c8743 in Consumer::execute() orchagent/orch.cpp:235
#13 0x555559090dad in OrchDaemon::start() orchagent/orchdaemon.cpp:755
#14 0x555558e9be25 in main orchagent/main.cpp:766
#15 0x7f0a299b6d09 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x23d09)
```
mssonicbld
added a commit
to mssonicbld/sonic-swss
that referenced
this pull request
Feb 4, 2025
…tries in gRouteBulker <!-- Please make sure you have read and understood the contribution guildlines: https://github.com/Azure/SONiC/blob/gh-pages/CONTRIBUTING.md 1. Make sure your commit includes a signature generted with `git commit -s` 2. Make sure your commit title follows the correct format: [component]: description 3. Make sure your commit message contains enough details about the change and related tests 4. Make sure your pull request adds related reviewers, asignees, labels Please also provide the following information in this pull request: --> **What I did** Avoid removing a VRF routing table when there are pending creation entries in gRouteBulker 1. Remove a VRF routing table when a routing entry is removed only if there is no pending creation entry in gRouteBulker 2. Avoid uninitialized value SAI IP address/prefix structure **Why I did it** Fix issue: out of range exception can be thrown in `addRoutePost` due to non exist VRF ``` (gdb) bt #0 0x00007f5791aedebc in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007f5791a9efb2 in raise () from /lib/x86_64-linux-gnu/libc.so.6 sonic-net#2 0x00007f5791a89472 in abort () from /lib/x86_64-linux-gnu/libc.so.6 sonic-net#3 0x00007f5791de0919 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6 sonic-net#4 0x00007f5791debe1a in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6 sonic-net#5 0x00007f5791debe85 in std::terminate() () from /lib/x86_64-linux-gnu/libstdc++.so.6 sonic-net#6 0x00007f5791dec0d8 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6 sonic-net#7 0x00007f5791de3240 in std::__throw_out_of_range(char const*) () from /lib/x86_64-linux-gnu/libstdc++.so.6 sonic-net#8 0x00005594e856d956 in std::map<unsigned long, std::map<swss::IpPrefix, RouteNhg, std::less<swss::IpPrefix>, std::allocator<std::pair<swss::IpPrefix const, RouteNhg> > >, std::less<unsigned long>, std::allocator<std::pair<unsigned long const, std::map<swss::IpPrefix, RouteNhg, std::less<swss::IpPrefix>, std::allocator<std::pair<swss::IpPrefix const, RouteNhg> > > > > >::at (this=<optimized out>, __k=<optimized out>) at /usr/include/c++/12/bits/stl_map.h:551 sonic-net#9 0x00005594e8564beb in RouteOrch::addRoutePost (this=this@entry=0x5594ea13e080, ctx=..., nextHops=...) at ./orchagent/routeorch.cpp:2145 sonic-net#10 0x00005594e856b0b2 in RouteOrch::doTask (this=0x5594ea13e080, consumer=...) at ./orchagent/routeorch.cpp:1021 sonic-net#11 0x00005594e85282d2 in Orch::doTask (this=0x5594ea13e080) at ./orchagent/orch.cpp:553 sonic-net#12 0x00005594e851909a in OrchDaemon::start (this=this@entry=0x5594ea0a0950) at ./orchagent/orchdaemon.cpp:895 sonic-net#13 0x00005594e8485632 in main (argc=<optimized out>, argv=<optimized out>) at ./orchagent/main.cpp:818 ``` **How I verified it** Unit (mock) test **Details if related** Originally, it cleaned up a VRF routing table whenever a prefix of the VRF was removed if 1. there was no routing entry in the VRF routing table and 2. the prefix was not pending creation in gRouteBulker The motivation is to remove a VRF routing table if there is no routing entry in the VRF and no routing entry pending creation for that VRF. However, condition 2 does not guarantee that. The ideal way of the 2nd condition is to check pending creation entries of a certain VRF, which we can not do. So, we are using strict conditions here as the following: 1. there is no routing entry in the VRF routing table and 2. there is no pending creating routing entry in gRouteBulker regardless of which VRF it belongs to
mssonicbld
added a commit
that referenced
this pull request
Feb 5, 2025
…tries in gRouteBulker (#3493) <!-- Please make sure you have read and understood the contribution guildlines: https://github.com/Azure/SONiC/blob/gh-pages/CONTRIBUTING.md 1. Make sure your commit includes a signature generted with `git commit -s` 2. Make sure your commit title follows the correct format: [component]: description 3. Make sure your commit message contains enough details about the change and related tests 4. Make sure your pull request adds related reviewers, asignees, labels Please also provide the following information in this pull request: --> **What I did** Avoid removing a VRF routing table when there are pending creation entries in gRouteBulker 1. Remove a VRF routing table when a routing entry is removed only if there is no pending creation entry in gRouteBulker 2. Avoid uninitialized value SAI IP address/prefix structure **Why I did it** Fix issue: out of range exception can be thrown in `addRoutePost` due to non exist VRF ``` (gdb) bt #0 0x00007f5791aedebc in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007f5791a9efb2 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007f5791a89472 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x00007f5791de0919 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6 #4 0x00007f5791debe1a in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6 #5 0x00007f5791debe85 in std::terminate() () from /lib/x86_64-linux-gnu/libstdc++.so.6 #6 0x00007f5791dec0d8 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6 #7 0x00007f5791de3240 in std::__throw_out_of_range(char const*) () from /lib/x86_64-linux-gnu/libstdc++.so.6 #8 0x00005594e856d956 in std::map<unsigned long, std::map<swss::IpPrefix, RouteNhg, std::less<swss::IpPrefix>, std::allocator<std::pair<swss::IpPrefix const, RouteNhg> > >, std::less<unsigned long>, std::allocator<std::pair<unsigned long const, std::map<swss::IpPrefix, RouteNhg, std::less<swss::IpPrefix>, std::allocator<std::pair<swss::IpPrefix const, RouteNhg> > > > > >::at (this=<optimized out>, __k=<optimized out>) at /usr/include/c++/12/bits/stl_map.h:551 #9 0x00005594e8564beb in RouteOrch::addRoutePost (this=this@entry=0x5594ea13e080, ctx=..., nextHops=...) at ./orchagent/routeorch.cpp:2145 #10 0x00005594e856b0b2 in RouteOrch::doTask (this=0x5594ea13e080, consumer=...) at ./orchagent/routeorch.cpp:1021 #11 0x00005594e85282d2 in Orch::doTask (this=0x5594ea13e080) at ./orchagent/orch.cpp:553 #12 0x00005594e851909a in OrchDaemon::start (this=this@entry=0x5594ea0a0950) at ./orchagent/orchdaemon.cpp:895 #13 0x00005594e8485632 in main (argc=<optimized out>, argv=<optimized out>) at ./orchagent/main.cpp:818 ``` **How I verified it** Unit (mock) test **Details if related** Originally, it cleaned up a VRF routing table whenever a prefix of the VRF was removed if 1. there was no routing entry in the VRF routing table and 2. the prefix was not pending creation in gRouteBulker The motivation is to remove a VRF routing table if there is no routing entry in the VRF and no routing entry pending creation for that VRF. However, condition 2 does not guarantee that. The ideal way of the 2nd condition is to check pending creation entries of a certain VRF, which we can not do. So, we are using strict conditions here as the following: 1. there is no routing entry in the VRF routing table and 2. there is no pending creating routing entry in gRouteBulker regardless of which VRF it belongs to
mssonicbld
added a commit
to mssonicbld/sonic-swss
that referenced
this pull request
Feb 20, 2025
…tries in gRouteBulker <!-- Please make sure you have read and understood the contribution guildlines: https://github.com/Azure/SONiC/blob/gh-pages/CONTRIBUTING.md 1. Make sure your commit includes a signature generted with `git commit -s` 2. Make sure your commit title follows the correct format: [component]: description 3. Make sure your commit message contains enough details about the change and related tests 4. Make sure your pull request adds related reviewers, asignees, labels Please also provide the following information in this pull request: --> **What I did** Avoid removing a VRF routing table when there are pending creation entries in gRouteBulker 1. Remove a VRF routing table when a routing entry is removed only if there is no pending creation entry in gRouteBulker 2. Avoid uninitialized value SAI IP address/prefix structure **Why I did it** Fix issue: out of range exception can be thrown in `addRoutePost` due to non exist VRF ``` (gdb) bt #0 0x00007f5791aedebc in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007f5791a9efb2 in raise () from /lib/x86_64-linux-gnu/libc.so.6 sonic-net#2 0x00007f5791a89472 in abort () from /lib/x86_64-linux-gnu/libc.so.6 sonic-net#3 0x00007f5791de0919 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6 sonic-net#4 0x00007f5791debe1a in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6 sonic-net#5 0x00007f5791debe85 in std::terminate() () from /lib/x86_64-linux-gnu/libstdc++.so.6 sonic-net#6 0x00007f5791dec0d8 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6 sonic-net#7 0x00007f5791de3240 in std::__throw_out_of_range(char const*) () from /lib/x86_64-linux-gnu/libstdc++.so.6 sonic-net#8 0x00005594e856d956 in std::map<unsigned long, std::map<swss::IpPrefix, RouteNhg, std::less<swss::IpPrefix>, std::allocator<std::pair<swss::IpPrefix const, RouteNhg> > >, std::less<unsigned long>, std::allocator<std::pair<unsigned long const, std::map<swss::IpPrefix, RouteNhg, std::less<swss::IpPrefix>, std::allocator<std::pair<swss::IpPrefix const, RouteNhg> > > > > >::at (this=<optimized out>, __k=<optimized out>) at /usr/include/c++/12/bits/stl_map.h:551 sonic-net#9 0x00005594e8564beb in RouteOrch::addRoutePost (this=this@entry=0x5594ea13e080, ctx=..., nextHops=...) at ./orchagent/routeorch.cpp:2145 sonic-net#10 0x00005594e856b0b2 in RouteOrch::doTask (this=0x5594ea13e080, consumer=...) at ./orchagent/routeorch.cpp:1021 sonic-net#11 0x00005594e85282d2 in Orch::doTask (this=0x5594ea13e080) at ./orchagent/orch.cpp:553 sonic-net#12 0x00005594e851909a in OrchDaemon::start (this=this@entry=0x5594ea0a0950) at ./orchagent/orchdaemon.cpp:895 sonic-net#13 0x00005594e8485632 in main (argc=<optimized out>, argv=<optimized out>) at ./orchagent/main.cpp:818 ``` **How I verified it** Unit (mock) test **Details if related** Originally, it cleaned up a VRF routing table whenever a prefix of the VRF was removed if 1. there was no routing entry in the VRF routing table and 2. the prefix was not pending creation in gRouteBulker The motivation is to remove a VRF routing table if there is no routing entry in the VRF and no routing entry pending creation for that VRF. However, condition 2 does not guarantee that. The ideal way of the 2nd condition is to check pending creation entries of a certain VRF, which we can not do. So, we are using strict conditions here as the following: 1. there is no routing entry in the VRF routing table and 2. there is no pending creating routing entry in gRouteBulker regardless of which VRF it belongs to
mssonicbld
added a commit
that referenced
this pull request
Feb 20, 2025
…tries in gRouteBulker (#3526) <!-- Please make sure you have read and understood the contribution guildlines: https://github.com/Azure/SONiC/blob/gh-pages/CONTRIBUTING.md 1. Make sure your commit includes a signature generted with `git commit -s` 2. Make sure your commit title follows the correct format: [component]: description 3. Make sure your commit message contains enough details about the change and related tests 4. Make sure your pull request adds related reviewers, asignees, labels Please also provide the following information in this pull request: --> **What I did** Avoid removing a VRF routing table when there are pending creation entries in gRouteBulker 1. Remove a VRF routing table when a routing entry is removed only if there is no pending creation entry in gRouteBulker 2. Avoid uninitialized value SAI IP address/prefix structure **Why I did it** Fix issue: out of range exception can be thrown in `addRoutePost` due to non exist VRF ``` (gdb) bt #0 0x00007f5791aedebc in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007f5791a9efb2 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007f5791a89472 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x00007f5791de0919 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6 #4 0x00007f5791debe1a in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6 #5 0x00007f5791debe85 in std::terminate() () from /lib/x86_64-linux-gnu/libstdc++.so.6 #6 0x00007f5791dec0d8 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6 #7 0x00007f5791de3240 in std::__throw_out_of_range(char const*) () from /lib/x86_64-linux-gnu/libstdc++.so.6 #8 0x00005594e856d956 in std::map<unsigned long, std::map<swss::IpPrefix, RouteNhg, std::less<swss::IpPrefix>, std::allocator<std::pair<swss::IpPrefix const, RouteNhg> > >, std::less<unsigned long>, std::allocator<std::pair<unsigned long const, std::map<swss::IpPrefix, RouteNhg, std::less<swss::IpPrefix>, std::allocator<std::pair<swss::IpPrefix const, RouteNhg> > > > > >::at (this=<optimized out>, __k=<optimized out>) at /usr/include/c++/12/bits/stl_map.h:551 #9 0x00005594e8564beb in RouteOrch::addRoutePost (this=this@entry=0x5594ea13e080, ctx=..., nextHops=...) at ./orchagent/routeorch.cpp:2145 #10 0x00005594e856b0b2 in RouteOrch::doTask (this=0x5594ea13e080, consumer=...) at ./orchagent/routeorch.cpp:1021 #11 0x00005594e85282d2 in Orch::doTask (this=0x5594ea13e080) at ./orchagent/orch.cpp:553 #12 0x00005594e851909a in OrchDaemon::start (this=this@entry=0x5594ea0a0950) at ./orchagent/orchdaemon.cpp:895 #13 0x00005594e8485632 in main (argc=<optimized out>, argv=<optimized out>) at ./orchagent/main.cpp:818 ``` **How I verified it** Unit (mock) test **Details if related** Originally, it cleaned up a VRF routing table whenever a prefix of the VRF was removed if 1. there was no routing entry in the VRF routing table and 2. the prefix was not pending creation in gRouteBulker The motivation is to remove a VRF routing table if there is no routing entry in the VRF and no routing entry pending creation for that VRF. However, condition 2 does not guarantee that. The ideal way of the 2nd condition is to check pending creation entries of a certain VRF, which we can not do. So, we are using strict conditions here as the following: 1. there is no routing entry in the VRF routing table and 2. there is no pending creating routing entry in gRouteBulker regardless of which VRF it belongs to
Janetxxx
pushed a commit
to Janetxxx/sonic-swss
that referenced
this pull request
Nov 10, 2025
**What I did**
Fix the Mem Leak by moving the raw pointers in type_maps to use smart pointers
**Why I did it**
```
Indirect leak of 83776 byte(s) in 476 object(s) allocated from:
#0 0x7f0a2a414647 in operator new(unsigned long) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:99
Pterosaur#1 0x5555590cc923 in __gnu_cxx::new_allocator, std::allocator > const, referenced_object> > >::allocate(unsigned long, void const*) /usr/include/c++/10/ext/new_allocator.h:115
Pterosaur#2 0x5555590cc923 in std::allocator_traits, std::allocator > const, referenced_object> > > >::allocate(std::allocator, std::allocator > const, referenced_object> > >&, unsigned long) /usr/include/c++/10/bits/alloc_traits.h:460
Pterosaur#3 0x5555590cc923 in std::_Rb_tree, std::allocator >, std::pair, std::allocator > const, referenced_object>, std::_Select1st, std::allocator > const, referenced_object> >, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::_M_get_node() /usr/include/c++/10/bits/stl_tree.h:584
Pterosaur#4 0x5555590cc923 in std::_Rb_tree_node, std::allocator > const, referenced_object> >* std::_Rb_tree, std::allocator >, std::pair, std::allocator > const, referenced_object>, std::_Select1st, std::allocator > const, referenced_object> >, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::_M_create_node, std::allocator > const&>, std::tuple<> >(std::piecewise_construct_t const&, std::tuple, std::allocator > const&>&&, std::tuple<>&&) /usr/include/c++/10/bits/stl_tree.h:634
Pterosaur#5 0x5555590cc923 in std::_Rb_tree_iterator, std::allocator > const, referenced_object> > std::_Rb_tree, std::allocator >, std::pair, std::allocator > const, referenced_object>, std::_Select1st, std::allocator > const, referenced_object> >, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::_M_emplace_hint_unique, std::allocator > const&>, std::tuple<> >(std::_Rb_tree_const_iterator, std::allocator > const, referenced_object> >, std::piecewise_construct_t const&, std::tuple, std::allocator > const&>&&, std::tuple<>&&) /usr/include/c++/10/bits/stl_tree.h:2461
Pterosaur#6 0x5555590e8757 in std::map, std::allocator >, referenced_object, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::operator[](std::__cxx11::basic_string, std::allocator > const&) /usr/include/c++/10/bits/stl_map.h:501
sonic-net#7 0x5555590d48b0 in Orch::setObjectReference(std::map, std::allocator >, std::map, std::allocator >, referenced_object, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >*, std::less, std::allocator > >, std::allocator, std::allocator > const, std::map, std::allocator >, referenced_object, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >*> > >&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&) orchagent/orch.cpp:450
sonic-net#8 0x5555594ff66b in QosOrch::handleQueueTable(Consumer&, std::tuple, std::allocator >, std::__cxx11::basic_string, std::allocator >, std::vector, std::allocator >, std::__cxx11::basic_string, std::allocator > >, std::allocator, std::allocator >, std::__cxx11::basic_string, std::allocator > > > > >&) orchagent/qosorch.cpp:1763
sonic-net#9 0x5555594edbd6 in QosOrch::doTask(Consumer&) orchagent/qosorch.cpp:2179
sonic-net#10 0x5555590c8743 in Consumer::drain() orchagent/orch.cpp:241
sonic-net#11 0x5555590c8743 in Consumer::drain() orchagent/orch.cpp:238
sonic-net#12 0x5555590c8743 in Consumer::execute() orchagent/orch.cpp:235
sonic-net#13 0x555559090dad in OrchDaemon::start() orchagent/orchdaemon.cpp:755
sonic-net#14 0x555558e9be25 in main orchagent/main.cpp:766
sonic-net#15 0x7f0a299b6d09 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x23d09)
```
jianyuewu
pushed a commit
to jianyuewu/sonic-swss
that referenced
this pull request
Dec 24, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.