Hi Dave, the reason why I went the gdbserver way is this:
Attaching to program: /home/ksekera/vpp/build-root/install-vpp_lite_debug-native/vpp/bin/vpp, process 7101 Could not attach to process. If your uid matches the uid of the target process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf ptrace: Operation not permitted. I know this can be tuned, but I wanted it to be as user friendly as possible. One might need to work on a machine where one doesn't have sudo rights (like the aurora boxes). I agree with the sucking part re gdb server, but so far it worked fine for me. It's just a different line to copy-paste. The only drawback I see with the gdbserver is the need to check for user stupidity in case the user just hints enter blindly, while VPP is stuck in gdb server - but I've added a warning for that case so that's done. Do you know of any other reasons for not using gdb server? Otherwise the flow is the same as you describe - wait for ENTER and run the testcase. Now that I think about it, we can have both, S=1 for server, G=1 for just waiting for the user to attach the gdb if you want. Maybe even give it more descriptive names? Thanks, Klement On Fri, Oct 28, 2016 at 07:26:34PM +0200, Dave Barach (dbarach) wrote: > 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: [1]vpp-dev-boun...@lists.fd.io > [[2]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: [3]vpp-dev@lists.fd.io > > > Cc: [4]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: > [5]https://jira.fd.io/browse/VPP-518 > > > > > > Regards, > > > Jan > > > > > > > > _______________________________________________ > > > vpp-dev mailing list > > > [6]vpp-dev@lists.fd.io > > > [7]https://lists.fd.io/mailman/listinfo/vpp-dev > > References > > Visible links > 1. mailto:vpp-dev-boun...@lists.fd.io > 2. mailto:vpp-dev-boun...@lists.fd.io > 3. mailto:vpp-dev@lists.fd.io > 4. mailto:csit-...@lists.fd.io > 5. https://jira.fd.io/browse/VPP-518 > 6. mailto:vpp-dev@lists.fd.io > 7. 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
