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

[Peter Dalgaard]

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

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.


-- 
    O__  ---- Peter Dalgaard             Øster Farimagsgade 5, Entr.B
   c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
  (*) \(*) -- University of Copenhagen   Denmark      Ph:  (+45) 35327918
~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)              FAX: (+45) 35327907