There is also an attempt to clean up processes left bind in a shell
script test/scripts/run_in_venv_with_cleanup.sh . I don't understand why
it doesn't work in this case...
Thanks,
Klement
Quoting Dave Wallace (2018-11-16 20:39:23)
>I'll see if I can reproduce the issue.
>
>I seem to rec
I'll see if I can reproduce the issue.
I seem to recall some python test code which was supposed to detect that
condition and clean up, but I don't think that I ever verified that it
worked.
Thanks,
-daw-
On 11/16/2018 11:44 AM, Florin Coras wrote:
I also noticed that although it shouldn’t
I also noticed that although it shouldn’t be different from the vcl test apps
which seem to be properly killed on test failure. Anyway, it’s on my todo list,
if nobody beats me to it.
Florin
> On Nov 16, 2018, at 5:27 AM, Klement Sekera wrote:
>
> I've also noticed that quite often a binary c
I've also noticed that quite often a binary called sock_test_client is
left running after a vpp crash or test failure. What's worse, it eats
100% CPU.
Quoting Florin Coras (2018-11-16 00:40:06)
>Thanks, Dave!
>I’ll take a look at those as soon as I can. I’m running multiple
>connection
No, it's on my laptop and out of 16g mem, 11g is caches so there
shouldn't be any OOM issue there.
Unless you change TEST_JOBS option (setting it to either auto or ), the test framework still runs 1 job at a time.
Klement
Quoting Florin Coras (2018-11-15 22:16:05)
> That’s an interesting failure
Thanks, Dave!
I’ll take a look at those as soon as I can. I’m running multiple connections
between 2 vpp hosts without issue, so it’s either a cut-through session issue
or it has to do with how we setup vpp for vrf leaking.
Cheers,
Florin
> On Nov 15, 2018, at 3:00 PM, Dave Wallace wrote:
>
Same here. However, in the same workspace where all tests passed, I can
get this test case to fail consistently:
EXTENDED_TESTS=y TEST=vcl.VCLThruHostStackExtendedBTestCase.* make test
EXTENDED_TESTS=y TEST=vcl.VCLIpv6ThruHostStackExtendedBTestCase.* make test
In patch 13215, I discovered that
That’s an interesting failure. Is the test machine running out of memory?
The extended tests are unstable on my server, so I do see quite a number of
failures. However this:
make test-ext TEST=vcl.VCLCutThruTestCase.test_vcl_cut_thru_uni_dir_nsock
runs just fine. After the latest test framework
I'm seeing timeouts and coredumps...
e.g.
#6 0x7f9ba0404eb6 in svm_msg_q_try_lock (mq=0x204009440)
at /home/ksekera/vpp/src/svm/message_queue.h:299
299 return pthread_mutex_trylock (&mq->q->mutex);
(gdb) p mq
$1 = (svm_msg_q_t *) 0x204009440
(gdb) p mq->q
$2 = (svm_queue_t *) 0x0
whic
Klement,
I just pulled the top-of-tree on master and ran only VCL tests on my
18.04 box and they all passed (see below). Another strange thing about
your failure is that the test that failed is NOT an extended test.
I'm currently working on a patch (https://gerrit.fd.io/r/#/c/13215/) to
sho
From: Klement Sekera via Lists.Fd.Io [mailto:ksekera=cisco@lists.fd.io]
Sent: Thursday, November 15, 2018 11:47 AM
To: vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: [vpp-dev] test-ext failures seen on master
Hi all,
I'm seeing failures on master branch on ubuntu 18.04 when invo
Hi all,
I'm seeing failures on master branch on ubuntu 18.04 when invoking `make
test-ext`
FAILURES AND ERRORS IN TESTS:
Testcase name: VCL Cut Thru Tests
FAILURE: run VCL cut thru uni-directional (multiple sockets) test
Testcase name: L2BD Test Case
ERROR: L2BD MAC learning dual
12 matches
Mail list logo
