cannot build R-devel (>= r49747)

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.