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

Sorry, I wasn't aware, .c files would be scrubbed. Testcase available for 
download here:
http://rkward.sourceforge.net/temp/threadEmbed.c

On Monday 17 April 2006 21:11, Thomas Friedrichsmeier wrote:
> 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/eab7be0e/attachment.bin 


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