[Rd] tests/ok-errors.R ## bad infinite recursion

[George Georgalis]

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.

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.

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  root at chime:/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 at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> -- 
> Brian D. Ripley,                  ripley at stats.ox.ac.uk
> 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><