xenofarm fuzz

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

[Stephen R. van den Berg]

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?
--
Sincerely,
           Stephen R. van den Berg.
The first 90% of code accounts for the first 90% of development time.
The remaining 10% of code accounts for the other 90% of development time.

I don't see how limiting memory or CPU could cause that... :p

[Stephen R. van den Berg]

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).
--
Sincerely,
           Stephen R. van den Berg.
"Having a non-smoking section in a restaurant is like
 having a non-peeing section in a pool."

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?

Probably.  Also, rtldebug in itself adds _lots_ of overhead.

>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...).

...closer to *50 times* slower than without? :p