Dear Klement,
Debugging w/ coredumps is just about worth supporting. I won't use it, but someone else might. Personally, I'd forget it. Debugging w/ gdbserver is a total fail. No need to support it. Gdbserver sucks. What I'm doing right now which is simple and effective: after starting vpp, but before doing anything: print the vpp pid, and [in the cave-man dbarach hack version] sleep for a while. In the non-caveman version, wait until the user types "<return>". Meanwhile, in another window: start gdb + emacs on the vpp-lite executable. Once the vpp pid is obvious: type "(gdb) attach <pid>". Set breakpoints as desired, then type "continue". That's the slick / adult way to debug vpp. By the way, the L2BD test failure seems related to using the same mac address on multiple interfaces. That's prima facie illegal. Please don't do that. I see the code add these 4 raw keys to the l2 FIB: 2: /x key0.raw = 0x101ff0000000001 2: /x key0.raw = 0x201ff0000000001 2: /x key0.raw = 0x301ff0000000001 2: /x key0.raw = 0x401ff0000000001 Take the mild assumption that these numbers hash to values which won't differ in low-order bits. Contestant #5 comes along, and runs the hash table out of memory trying to pry these entries apart. I'll go make sure that I'm right - after lunch - but I'd STRONGLY suggest trying different MAC addresses if you want the test to pass instantaneously... Thanks... Dave -----Original Message----- From: Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco) Sent: Friday, October 28, 2016 12:47 PM To: Dave Barach (dbarach) <dbar...@cisco.com> Cc: Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) <jgel...@cisco.com>; vpp-dev@lists.fd.io; csit-...@lists.fd.io Subject: Re: [vpp-dev] L2BD test failing during MAC learning - VPP-518 Hi Dave, 2 options: 1.) if you set ulimit -c properly and do a make test-debug I=1 TEST=l2bd (or just make test-debug I=1), the test framework should detect the core, fire up a gdb, load it and give you control (I stands for "interactive" here) 2.) this one is not committed yet, but I have a patch which adds S=1 for running in gdbserver from the start - so at the beginning of each test case, it starts the vpp in gdbserver, prints the command line to attach gdb and waits for an <ENTER> so that you can set breakpoints etc.. I hope to push this to gerrit soon... Thanks, Klement On Fri, Oct 28, 2016 at 04:17:48PM +0000, Dave Barach (dbarach) wrote: > Dear Jan, > > This looks for all the world like a bounded-index extensible hash jackpot. If > that's so, the fix is obvious but it will take a bit of time to code and test. > > Before I go there, I'll need to blow it up myself and poke around in gdb. > Have folks implemented the scheme I asked for - to pause test(s) so a > developer can attach to vpp from gdb - before anything else happens? > > If not, I can stick a sleep into the test BUT that feature request is very > important. > > Thanks... Dave > > From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io> > [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Jan Gelety -X (jgelety - > PANTHEON TECHNOLOGIES at Cisco) > Sent: Friday, October 28, 2016 12:02 PM > To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> > Cc: csit-...@lists.fd.io<mailto:csit-...@lists.fd.io> > Subject: [vpp-dev] L2BD test failing during MAC learning - VPP-518 > > Dear vpp developers, > > We found out that VPP crashes during the MAC learning when run L2BD test that > is part of the test framework. The issue is reported here: > https://jira.fd.io/browse/VPP-518 > > Regards, > Jan > > _______________________________________________ > vpp-dev mailing list > vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> > https://lists.fd.io/mailman/listinfo/vpp-dev
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
