Why not raise your limits to more reasonable levels? These failures are
warning you that your limits (stack, it looks) are too low.
We do know from experience on Windows that a 2Mb stack limit is too low,
and recommend 10Mb (and that is on a 32-bit system).
Also, the descriptors limit should be at least 128 (and no system we
looked at recently had less than 256).
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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
