The test has warned you about a problem with your OS, and I have already
told you how to solve it. If you don't want to do that, the test will
continue to remind you.
On Fri, 23 May 2008, George Georgalis wrote:
On Thu 22 May 2008 at 07:09:51 PM +0100, Prof Brian Ripley wrote:
Why not raise your limits to more reasonable levels? These failures are
warning you that your limits (stack, it looks) are too low.
These are the default netbsd levels (soft limit). As a user I
can raise the stack to 3072 and the test exits with the expected
result.
However, isn't the purpose of the test to identify if something is
wrong? The problem is: there was _no_failure_ when the ulimit was
reached! When the stack limit is reached the process adds 1 to
the load and does not log or return.
An arbitrary amount of stack may be used before a 'recursive
infinite loop is invoked' so just raising the ulimit doesn't
fix anything other than making the test pass, it just hides the
problem.
Your assertion is simply wrong -- the amount is not 'arbitrary'.
These ulimits have been in place for some time on our production
systems, with no problem. Only problem we have experienced is the
test script.
Incidentally ktrace did not indicate what was going on after the
process reached point of no return.
Also, the descriptors limit should be at least 128 (and no system we looked
at recently had less than 256).
We have never run out of file descriptors, and given our modeling
tasks, it is unlikely this will ever happen.
At this point I'm looking for a consensus as to whether the shell,
kernel, or R should kill the process when the stack (or another)
ulimit is reached.
R (where possible) stops this being reached -- you seem unfamiliar with
the R manuals.
I'm thinking it is the kernel/shell that should kill a process
that touches a ulimit; but I'm not 100% on this.
// George
On Thu, 22 May 2008, George Georgalis wrote:
I've come across a handful of tests that
fail at our site. I consider this one the
worst because the process does not return.
The patch below simply bypasss the test,
but the errors in the out file are included
as well. I suspect this is due to more or
tighter ulimits on this system.
But I'm not sure if this is result of
different expectations (kernel/userland) of
what should be done in the curcumstance.
// George
NetBSD chime 4.0_STABLE NetBSD 4.0_STABLE (CHIME) #6: Tue Apr 29 16:49:55 EDT
2008 [EMAIL PROTECTED]:/usr/obj/sys/arch/amd64/compile/CHIME amd64
time(cpu-seconds) unlimited
file(blocks) unlimited
coredump(blocks) 1
data(kbytes) 262144
stack(kbytes) 2048
lockedmem(kbytes) 670964
memory(kbytes) 2012892
nofiles(descriptors) 64
processes 160
sbsize(bytes) unlimited
--- ok-errors.R.orig 2007-09-25 18:05:05.000000000 -0400
+++ ok-errors.R 2008-05-21 16:09:12.000000000 -0400
@@ -16,7 +16,40 @@
getenv("USER") # should produce correct error message.
-## bad infinite recursion / on.exit / ... interactions
-bar <- function() 1+1
-foo <- function() { on.exit(bar()); foo() }
-foo() # now simple "infinite recursion"
+### bad infinite recursion / on.exit / ... interactions
+#bar <- function() 1+1
+#foo <- function() { on.exit(bar()); foo() }
+#foo() # now simple "infinite recursion"
+#
+#
+#> ## bad infinite recursion / on.exit / ... interactions
+#> bar <- function() 1+1
+#> foo <- function() { on.exit(bar()); foo() }
+#> foo() # now simple "infinite recursion"
+#Error: C stack usage is too close to the limit
+#Error: C stack usage is too close to the limit
+#Error: C stack usage is too close to the limit
+#Error: C stack usage is too close to the limit
+#Error: C stack usage is too close to the limit
+#Error: segfault from C stack overflow
+#Error: C stack usage is too close to the limit
+#Error during wrapup: C stack usage is too close to the limit
+#Error: C stack usage is too close to the limit
+#Error during wrapup: C stack usage is too close to the limit
+#Error: C stack usage is too close to the limit
+#Error during wrapup: C stack usage is too close to the limit
+#Error: C stack usage is too close to the limit
+#Error during wrapup: C stack usage is too close to the limit
+#Error: C stack usage is too close to the limit
+#Error during wrapup: C stack usage is too close to the limit
+#Error: C stack usage is too close to the limit
+#Error during wrapup: C stack usage is too close to the limit
+#Error: C stack usage is too close to the limit
+#Error during wrapup: C stack usage is too close to the limit
+#Error: C stack usage is too close to the limit
+#Error during wrapup: C stack usage is too close to the limit
+#Error: C stack usage is too close to the limit
+#Error during wrapup: C stack usage is too close to the limit
+#Error: C stack usage is too close to the limit
+#
+# and machine remains at load of 1, R process does not exit or log for several
minutes.
--
George Georgalis, information system scientist <IXOYE><
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
--
George Georgalis, information system scientist <IXOYE><
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
