Petr Rockai wrote: > The most interesting test I can currently think of is to run the harness > (i.e. Setup) in valgrind. Without buildbot first (it may be that the bug is > always there, but the subtle difference in environment causes it not to > trigger > -- valgrind may still detect it though) and if that fails within buildbot.
To get it back to the earth. We're talking about issue on OpenBSD 4.4 buildbot here and OpenBSD does not provide valgrind. Valgrind is quite Linux-only beast. More importantly: bash-3.2$ pwd /home/buildbot bash-3.2$ ulimit -a core file size (blocks, -c) unlimited data seg size (kbytes, -d) 524288 file size (blocks, -f) unlimited max locked memory (kbytes, -l) 164961 max memory size (kbytes, -m) 493264 open files (-n) 128 pipe size (512 bytes, -p) 1 stack size (kbytes, -s) 4096 cpu time (seconds, -t) unlimited max user processes (-u) 64 virtual memory (kbytes, -v) 528384 bash-3.2$ find . -name 'core*' bash-3.2$ translated to human language this means: although core file size is unlimited hence OS is allowed to save the core of the crashing process, there is no core file in the buildbot home. i.e. darcs probably has not segfaulted. Cheers, Karel _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
