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

George Georgalis george at galis.org
Sun May 25 04:27:57 CEST 2008


On Sat 24 May 2008 at 08:04:03 AM +0100, Prof Brian Ripley wrote:
> The test has warned you about a problem with your OS,

Well we have been digging a little deeper, here is a ktrace
http://pastebin.ca/1028465

there is lots of checks/warnings that the stack limit is
getting close, but when R hits the limit it gets SIGSEGV
and should abort, longjmp or something (line 194):

 14824      1 R        PSIG  SIGSEGV caught handler=0x411a90 mask=(): code=SEGV_ACCERR, addr=0x7f7fffdff670, trap=6)

What it actually does is try to wrapup and such till it
hits line 330, at which point it sits, uses cycles, till
I ctrl-c it on line 331.

I think when it gets SIGSEGV it should exit, but it
would seem the "C stack usage is too close to the limit"
to stderr checks or some other use of resources to wrap
up are causing failure to exit. Warnings about stack
running out are cool but not if the check causes the
process to hang when the resource does run out.

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

I don't see how raising the stack ulimit would fix
the problem; what if we had 768K on the stack before
invoking an infinite loop? The process would not exit
or progress. Exactly the problem the test is trying to
identify.

// George



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

-- 
George Georgalis, information system scientist <IXOYE><



More information about the R-devel mailing list