From thomas.friedrichsmeier at ruhr-uni-bochum.de  Mon Apr 17 21:11:53 2006
From: thomas.friedrichsmeier at ruhr-uni-bochum.de (Thomas Friedrichsmeier)
Date: Mon, 17 Apr 2006 21:11:53 +0200
Subject: [Rd] Testcase (was: Stack checking, core dumps, and embedding R)
In-Reply-To: <200604171520.51565.thomas.friedrichsmeier@ruhr-uni-bochum.de>
References: <200604170334.14003.thomas.friedrichsmeier@ruhr-uni-bochum.de>
	<200604171520.51565.thomas.friedrichsmeier@ruhr-uni-bochum.de>
Message-ID: <200604172111.58597.thomas.friedrichsmeier@ruhr-uni-bochum.de>

Sorry about all the noise, but I'm slightly irritated by the absence of 
reactions of any kind, while the time to the release is ticking away.

Attached you will find a testcase for the problem. Likely the error will only 
show up on linux, due to the

	#if defined(linux)
	    R_CStackStart = (uintptr_t) __libc_stack_end;
	#elif ...

in unix/system.c . Also the error may not be 100% reproducible, depending on 
where exactly the stack for the worker thread is allocated, but at least for 
me it has triggered every single time I tried it (recent debian unstable on a 
Pentium M, for reference).

For your convenience, if you place the testcase in tests/Embedding of your R 
source tree, here are the lines needed to compile and run:

gcc -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H   -g -O2 -std=gnu99 -c 
threadEmbed.c -o threadEmbed.o

../../bin/R CMD LINK gcc -o threadEmbed 
threadEmbed.o -L../../lib -lR -lpthread

(R_HOME=../..; export R_HOME; ./threadEmbed --silent)

Once again, I don't know how many embedding applications are affected by this, 
but it is absolutely fatal for rkward, at least. The proposed patch, cited 
again, below, fixes the problem.

Regards
Thomas

On Monday 17 April 2006 15:20, Thomas Friedrichsmeier wrote:
> Excuse me please, for being impatient, but I'm worried this issue may not
> be considered important enough to be fixed in R 2.3.0 at this late point of
> time. So let me re-state this:
>
> In the current state, R will *not work at all* when run in a thread on
> linux.
>
> I do not know how many embedding applications run R in a separate thread,
> and are affected by this. I know that at least rkward does, and it will not
> run.
>
> Reconsidering the proposals I made yesterday, after some sleep, let me
> propose this corrected fix (insert into src/unix/system.c, at line 179,
> right above "if(R_CStackStart == -1) R_CStackLimit = -1; /* never set */"):
>
>     if (abs (R_CStackStart - (uintptr_t) &i) > 20000) {
> 	/* Very unlikely we're this far away from the stack start at this
> 	point in the code. Disable checking */
> 	R_CStackStart = -1;
>     }
>
> For all I care, set the safety margin to 50000 or even more. This heuristic
> is only meant to catch cases where the detected value for R_CStackStart is
> *obviously wrong*, most importantly in case of threads.
>
> In this case all it will do is to disable the check. I can see no other
> side-effect.
>
> Once again, excuse me for being impatient, but *please* consider this for
> inclusion in R 2.3.0.
>
> Regards
> Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : https://stat.ethz.ch/pipermail/r-devel/attachments/20060417/bcc0bf09/attachment.bin 


[Rd] Testcase (was: Stack checking, core dumps, and embedding R)
Thomas Friedrichsmeier