Hm. Ok, so if I run "make verify" myself:
| Subresult: 40406 tests, 0 failed, 9 skipped | Accumulated: 158118 tests, 0 failed, 217 skipped | Total tests: 158118 (217 tests skipped) | Finished tests at Mon Sep 1 08:42:06 2008
but if xenofarm runs it,
| Doing tests in testsuite (11197 tests) [2 cpu-hours worth of computrons] | No result from subprocess (died of signal SIGKILL)
can anyone explain this? :p
Mirar @ Pike developers forum wrote:
Hm. Ok, so if I run "make verify" myself:
| Subresult: 40406 tests, 0 failed, 9 skipped | Accumulated: 158118 tests, 0 failed, 217 skipped | Total tests: 158118 (217 tests skipped) | Finished tests at Mon Sep 1 08:42:06 2008
but if xenofarm runs it,
| Doing tests in testsuite (11197 tests) [2 cpu-hours worth of computrons] | No result from subprocess (died of signal SIGKILL)
can anyone explain this? :p
ulimit?
Mirar @ Pike developers forum wrote:
I don't see how limiting memory or CPU could cause that... :p
Well, perhaps that dreaded OOM-killer of Linux (just about the only thing in Linux that I considered a very big mistake from the start).
Well, the xenofarm testing ("make verify") is considerably much more slow than a normal CVS build testing. It's been at it for 1h45 minutes now, which is pretty good since it's limited to 15 minutes by ulimit... Normal runtime is 1½ minute or so of cpu-time.
It is doing rtldebug and dmalloc though. Is dmalloc *that* slow?
Well, the xenofarm testing ("make verify") is considerably much more slow than a normal CVS build testing. It's been at it for 1h45 minutes now, which is pretty good since it's limited to 15 minutes by ulimit... Normal runtime is 1½ minute or so of cpu-time.
It is doing rtldebug and dmalloc though. Is dmalloc *that* slow?
Dmalloc in Pike 7.8 is ~10 times slower than the one in Pike 7.6. I'm right now attempting to find when it started getting slow (good opportunity to try git bisect...).
pike-devel@lists.lysator.liu.se
-
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Mirar ＠ Pike developers forum
-
Stephen R. van den Berg