[Rd] cannot build R-devel (>= r49747)

[Romain Francois]

Going a bit further. The problem happens when I "make" in the 
"src/library/base" directory at that step :

         @cat $(srcdir)/makebasedb.R | \
           R_DEFAULT_PACKAGES=NULL LC_ALL=C $(R_EXE) > /dev/null

I'm attaching the result of "make -d" in this directory.

However, this might be relevant about my setting, I have the 
"R_KEEP_PKG_SOURCE" environment variable set to "yes". And if I set it 
to "no" it builds correctly.

Romain

On 09/22/2009 09:33 AM, Romain Francois wrote:
>
> On 09/22/2009 09:17 AM, Peter Dalgaard wrote:
>>
>> Romain Francois wrote:
>>> Hello,
>>>
>>> I've tried several times yesterday to build R-devel and I consistently
>>> get this error when I "make" :
>>>
>>> mkdir -p -- ../../../library/base/R
>>> make[3]: Leaving directory `/tmp/R-devel/src/library/profile'
>>> make[3]: Entering directory `/tmp/R-devel/src/library/base'
>>> building package 'base'
>>> make[4]: Entering directory `/tmp/R-devel/src/library/base'
>>> mkdir -p -- ../../../library/base/demo
>>> mkdir -p -- ../../../library/base/po
>>> make[4]: Leaving directory `/tmp/R-devel/src/library/base'
>>> Error: unprotect_ptr: pointer not found
>>> Execution halted
>>> make[3]: *** [all] Error 1
>>> make[3]: Leaving directory `/tmp/R-devel/src/library/base'
>>> make[2]: *** [R] Error 1
>>> make[2]: Leaving directory `/tmp/R-devel/src/library'
>>> make[1]: *** [R] Error 1
>>> make[1]: Leaving directory `/tmp/R-devel/src'
>>> make: *** [R] Error 1
>>>
>>>
>>> I tried this morning to step down and I believe this has been
>>> introduced by rev 49747:
>>>
>>> -------------------------------------------------------------------------
>>>
>>> r49747 | murdoch | 2009-09-18 14:10:55 -0400 (Fri, 18 Sep 2009) | 1 line
>>> Changed paths:
>>> M /trunk/src/include/Defn.h
>>> M /trunk/src/include/Parse.h
>>> M /trunk/src/main/gram.c
>>> M /trunk/src/main/gram.y
>>> M /trunk/src/main/main.c
>>> M /trunk/src/main/memory.c
>>>
>>> Allow parsing in the middle of a REPL on a file, without messing up
>>> the source record for the file.
>>> -------------------------------------------------------------------------
>>>
>>>
>>> ... which makes sense since it looks like a parser issue.
>>>
>>> I can build revision 49746.
>>>
>>> This is a fedora 11 :
>>>
>>> $ uname -a
>>> Linux santorini 2.6.29.6-217.2.16.fc11.i686.PAE #1 SMP Mon Aug 24
>>> 17:16:21 EDT 2009 i686 i686 i386 GNU/Linux
>>>
>>> I'm not sure what I can do to help fixing this. Can someone else with
>>> a fedora replicate this ?
>>>
>>> Romain
>>>
>>
>> This could be pretty serious.
>>
>> unprotect_ptr is used where the usual PROTECT/UNPROTECT mechanisms don't
>> work because things do not follow strict stack discipline. The main spot
>> is when the parser uses lookahead to distinguish different constructs.
>
> Yes. This makes sense since rev 49747 was a fix to another bug when R
> reenters the parser. See the thread :
>
> "[Rd] 2.10.0 Under development (unstable) (2009-09-15 r49711) just built
> segfaults on Debian Squeeze"
>
>> I don't think I have ever seen it fail like that, but a possible reason
>> could be that the wrong pointer got removed from the protection stack.
>> Or memory corruption in the stack itself of course. A bit odd if the
>> former sort of bug should be unportable, though.
>>
>> It is not happening for me on 32bit fedora 9.
>
> Thanks for this. I'll digg a little deeper
>
>> It could be useful if you could drill a little further down to see
>> exactly how R is invoked at the failure, incl content input file(s), and
>> maybe redo the run with debugging turned on so that we can see who is
>> trying to unprotect what.
>



-- 
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/yw8E : New R package : sos
|- http://tr.im/y8y0 : search the graph gallery from R
`- http://tr.im/y8wY : new R package : ant

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: make.log
URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20090922/116802ca/attachment.pl>