[Rd] Wrong config check for __libc_stack_end

[Simon Urbanek]

On Feb 1, 2016, at 12:32 PM, Martin Maechler <maechler at stat.math.ethz.ch> wrote:

>>>>>> Simon Urbanek <simon.urbanek at r-project.org>
>>>>>>    on Mon, 1 Feb 2016 08:36:56 -0500 writes:
> 
>> On Feb 1, 2016, at 4:16 AM, Martin Maechler <maechler at stat.math.ethz.ch> wrote:
> 
> [..............]   
> 
>>> Back to R: I'm not familiar with that part of the code, neither
>>> the configuration, nor the usage (in  R/src/unix/system.c ).
>>> However, that code seems to be using a a glibc "feature" widely
>>> available which does help making R startup (a very tiny bit ??)
>>> faster.
>>> 
> 
>> No, it's actually very crucial as it is used to detect stack overflows.
> 
>> Cheers,
>> Simon
> 
> 
> Well, I think you misunderstood what I meant to say (or then I'm
> happy for clarification if I misunderstood you) :
> 
> The #ifdef ... #elseif ... #else ... # endif
> branch which *uses* the __libc_stack_end "variable" would
> hopefully be a speedup in comparison with the alternatives; from
> system.c  mentioned above:
> 
> 
> #if defined(HAVE_LIBC_STACK_END)
>    R_CStackStart = (uintptr_t) __libc_stack_end;
> #elif defined(HAVE_KERN_USRSTACK)
>    {
> 	/* Borrowed from mzscheme/gc/os_dep.c */
> 	int nm[2] = {CTL_KERN, KERN_USRSTACK};
> 	void * base;
> 	size_t len = sizeof(void *);
> 	(void) sysctl(nm, 2, &base, &len, NULL, 0);
> 	R_CStackStart = (uintptr_t) base;
>    }
> #else
>    if(R_running_as_main_program) {
> 	/* This is not the main program, but unless embedded it is
> 	   near the top, 5540 bytes away when checked. */
> 	R_CStackStart = (uintptr_t) &i + (6000 * R_CStackDir);
>    }
> #endif
>    if(R_CStackStart == -1) R_CStackLimit = -1; /* never set */
> 
>    /* printf("stack limit %ld, start %lx dir %d \n", R_CStackLimit,
> 	      R_CStackStart, R_CStackDir); */
> }
> #endif
> 
> so I'd hope that typically  R_CStackStart  would be set usefully
> also when the  __libc_stack_end  is not available.
> 
> If not, that would mean that for the 'musl' lovers, R would not
> be able to detect stack overflows.... which would probably be
> quite undesirable.
> 

But how do you know that the kernel method will work there? What I meant is that the facility it provides is important - it's unclear under what circumstances it is necessary or not - that depends on the kernel, OS, hardware etc. Hence __libc_stack_end is not just a speed hack (which your comment seemed to imply) - when available it is reliable and thus preferred, wheres are fallback methods may or may not work and to varying degree of reliability.

Cheers,
Simon