hi,
i noticed some issues with some pikefarm tests never completing.
since i was not sure which tests are useful, i started with all of them, and i find that feature, static and thorough in particular sometimes have issues
i have one that is currently stuck in pike 7.6 static, but on a previous build it did not get stuck there (from what i remember)
i tried to set a lower cpu time, but that made no difference. the test is now running for more than two days, and it seems to do nothing.
in other cases i had a test stuck at using the full cpu load for hours (that probably got stopped now with the lower cpu limit)
for pikefarm now i wonder, are these tests even still useful? i don't see anyone else running any of feature, static or thorough. are these not relevant anymore? should other tests be run instead? (i added a doc build test which i found useful already)
for xenofarm in general, is there a way to limit the time a test runs? (abort if it is running to long?)
greetings, martin.
I've been hacking on the test watchdog a bit lately, and now it should kill the right subprocess, at least when the socket tests in src/modules/files/ hangs. So there should hopefully not be any hung processes left behind anymore.
Then it's another question why that socket test hangs so often as it does. It might be related to -DIPV6 tests; the two instances I've found in xenofarm right now both hang there, at least. It occurs apparently random on many different hosts.
for pikefarm now i wonder, are these tests even still useful? i don't see anyone else running any of feature, static or thorough.
feature: Current config args are --with-cdebug --with-security --with-double-precision --with-profiling --with-keypair-loop --with-new-multisets. The new multiset implementation is on by default (it can't even be switched off anymore). --with-cdebug doesn't test anything useful, and besides it defaults to on most of the time. --with-double-precision can preferably be combined with --with-long-long-int.
static: It's always good to have a static build.
thorough: Seems to be "feature" combined with dmalloc. That can probably enable a couple more uncommon code regions. I'm not sure that there's any use having two builds with only that difference, though.
Some more "unusual" flags that could be nice to test are --without-machine-code and --without-threads, but they both disable large code regions so it wouldn't be wise to combine them with the other "unusual" flags in the "feature" build. The static build could test one of those too, though.
well, i'll be happy to test whatever is useful to you. most of these tests don't mean anything to me. (the only one that i found useful was building docs)
so it might be useful if you could just create a config file that the rest of us can download, listing tests in order of relevance.
(actually, i think a list of tests to be run could be in a file in the source snapshot, and the xenofarm client could pick it from there to get aditional tests. if the xenofarm client specifies an "all" metatarget, it could be used to mean, run all tests that are provided. that way you have more flexibility and control over what tests are run)
greetings, martin.
pike-devel@lists.lysator.liu.se