From ripley at stats.ox.ac.uk  Sat May 24 09:04:03 2008
From: ripley at stats.ox.ac.uk (Prof Brian Ripley)
Date: Sat, 24 May 2008 08:04:03 +0100 (BST)
Subject: [Rd] tests/ok-errors.R ## bad infinite recursion
In-Reply-To: <20080523190202.GD6697@sadie.duo>
References: <20080522172006.GC2895@sadie.duo>
	<alpine.LFD.1.10.0805221904540.27313@gannet.stats.ox.ac.uk>
	<20080523190202.GD6697@sadie.duo>
Message-ID: <alpine.LFD.1.10.0805240754490.5185@gannet.stats.ox.ac.uk>

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  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><
>
> ______________________________________________
> 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



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