> On Jul 17, 2015, at 9:33 AM, Ben Pfaff <b...@nicira.com> wrote:
>
> On Thu, Jul 16, 2015 at 05:22:25PM -0700, Jarno Rajahalme wrote:
>>
>>> On Jul 16, 2015, at 4:33 PM, Ben Pfaff <b...@nicira.com> wrote:
>>>
>>> On Thu, Jul 16, 2015 at 03:15:52PM -0700, Jarno Rajahalme wrote:
>>>> I've seen core files appear and then be automatically removed as the
>>>> test case was successful. Such success is highly doubtful, so fail
>>>> the test cases if any core files exist at the end of the test.
>>>>
>>>> Signed-off-by: Jarno Rajahalme <jrajaha...@nicira.com>
>>>
>>> I proposed a similar patch in May 2014:
>>> http://openvswitch.org/pipermail/dev/2014-May/040497.html
>>> but you didn't like it:
>>> http://openvswitch.org/pipermail/dev/2014-May/040857.html
>>
>> My comment at the time was that I did not see the result of the line
>>
>> echo "$core: core dumped during test"
>> anywhere, but now I see that this is simply due to the fact that the test
>> case failed on an earlier AT_CHECK and never got to checking the cores.
>
> I made the same argument before too:
> http://openvswitch.org/pipermail/dev/2014-June/041301.html
> <http://openvswitch.org/pipermail/dev/2014-June/041301.html>
> ;-)
>
>> So I see that this patch has the same limitation. Do you have any idea
>> how to check and report for core files regardless of the success or
>> failure of the test case? I think this would be important as I’ve seen
>> cores in both cases. In success case we currently lose the fact that
>> there even was a core dump, and this likely happens also in the
>> failure case if we blindly run a —recheck and by chance succeed that
>> time.
>>
>> Right now I habitually run “find . -name core -print” from a shell
>> after each “make check” that has any failures before a —recheck. I’d
>> like to automate this somehow! And this doesn’t even catch the cores
>> of successful test cases. The only reason I know they exist was due to
>> running the find command multiple times while “make check” was
>> running, and I saw some core files that had disappeared in later find
>> runs.
>
> Well, something like this would do it:
>
> diff --git a/tests/atlocal.in b/tests/atlocal.in
> index 5946a3c..5baa9ec 100644
> --- a/tests/atlocal.in
> +++ b/tests/atlocal.in
> @@ -110,3 +110,11 @@ fi
> if test "$IS_WIN32" = "yes"; then
> HAVE_PYTHON="no"
> fi
> +
> +trap '
> + if find "$at_suite_dir" -name core\* -print | grep .; then
> + echo
> + echo "WARNING: See above for list of core dumps produced by tests."
> + echo
> + fi
> +’ 0
I tested this by adding the new lines to atlocal.in, and making miniflow tests
artificially “core”:
diff --git a/tests/classifier.at b/tests/classifier.at
index 3520acd..68156ad 100644
--- a/tests/classifier.at
+++ b/tests/classifier.at
@@ -25,6 +25,7 @@ m4_foreach(
[minimask_combine]],
[AT_SETUP([miniflow - m4_bpatsubst(testname, [-], [ ])])
AT_CHECK([ovstest test-classifier testname], [0], [], [])
+ touch core.foo.bar
AT_CLEANUP])])
AT_BANNER([flow classifier lookup segmentation])
After this “make -k -j6 "TESTSUITEFLAGS=-k miniflow" check” still succeeds:
miniflow unit tests
90: miniflow - miniflow ok
91: miniflow - minimask_has_extra ok
92: miniflow - minimask_combine ok
I don’t know how the trap is supposed to work, so maybe I am missing something?
Jarno
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
