[Rd] tests/ok-errors.R ## bad infinite recursion
Prof Brian Ripley
ripley at stats.ox.ac.uk
Sat May 24 09:04:03 CEST 2008
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
More information about the R-devel
mailing list