R devel - Nov 2009 - Segmentation faults on SEXP conversion

Hello -

I am making a first attempt at writing a simple C++ routine to print
out R objects (this is a simple proof-of-concept as part of a larger
package development). The relevant C++ routine is as follows:

void Rwrite(SEXP fd, SEXP msg) {
  int *ofd = INTEGER(fd);
  const char * omsg = CHAR(asChar(msg));
  printf("[%i] %s",*ofd,omsg);
}

And the corresponding interface in R is as follows:

ptest <- function()
  {
    cfd <- as.integer(2);
    cmsg <- as.character("Hi");
    storage.mode(cfd) <- "integer";
    storage.mode(cmsg) <- "character";
    .Call("Rwrite",
          fd=cfd,
          msg=cmsg,
          PACKAGE="forkex"
       );
  }

Upon running the above code as a call to `ptest()`, I receive a
segmentation fault. Building the package as `R CMD check
--use-valgrind ...` provides the following memcheck output:
> ptest();
==12591== Invalid read of size 1
==12591==    at 0x4D04209: SET_SYMVALUE (in /usr/lib64/R/lib/libR.so)
==12591==    by 0x4D01E51: Rf_ReplIteration (in /usr/lib64/R/lib/libR.so)
==12591==    by 0x4D020B7: (within /usr/lib64/R/lib/libR.so)
==12591==    by 0x4D027CF: run_Rmainloop (in /usr/lib64/R/lib/libR.so)
==12591==    by 0x40083A: main (in /usr/lib64/R/bin/exec/R)
==12591==  Address 0x9 is not stack'd, malloc'd or (recently) free'd
[2] Hi
 *** caught segfault ***
address 0x9, cause 'memory not mapped'
aborting ...
==12591===12591== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 18 from
1)
==12591== malloc/free: in use at exit: 22,564,238 bytes in 10,614 blocks.
==12591== malloc/free: 29,096 allocs, 18,482 frees, 44,702,479 bytes allocated.
==12591== For counts of detected errors, rerun with: -v
==12591== searching for pointers to 10,614 not-freed blocks.
==12591== checked 19,665,464 bytes.
==12591===12591== LEAK SUMMARY:
==12591==    definitely lost: 0 bytes in 0 blocks.
==12591==      possibly lost: 0 bytes in 0 blocks.
==12591==    still reachable: 22,564,238 bytes in 10,614 blocks.
==12591==         suppressed: 0 bytes in 0 blocks.
==12591== Rerun with --leak-check=full to see details of leaked memory.

The same segmentation fault occurs whether I try passing either the
`int` or `character` or both (as in the above). I have not tried other
types. However, I have attempted various type conversions in the
Rdefines.h header, but cannot avoid the segmentation fault. This is
the only code in the proof-of-concept pacakage (aside from useDynLoad
related registration structures and the R_init_??? call).

I have a feeling it is something simple, but I am not well versed in R
package development at this point. Please let me know if other
information is helpful.

I am running Linux 2.6.27.30-170.2.82.fc10.x86_64 with R 2.10.0.

Thanks!

On 15/11/2009 1:41 PM, nabble.30.miller_2555 at spamgourmet.com
wrote:
> Hello -
> 
> I am making a first attempt at writing a simple C++ routine to print
> out R objects (this is a simple proof-of-concept as part of a larger
> package development). The relevant C++ routine is as follows:
> 
> void Rwrite(SEXP fd, SEXP msg) {
>   int *ofd = INTEGER(fd);
>   const char * omsg = CHAR(asChar(msg));
The "character" type in R corresponds to STRSXP in C, which is a
vector
of CHARSXPs.  So you need an extra step to get to the C string:

const char * omsg = CHAR(STRING_ELT(msg, 0));

Duncan Murdoch

>   printf("[%i] %s",*ofd,omsg);
> }
> 
> And the corresponding interface in R is as follows:
> 
> ptest <- function()
>   {
>     cfd <- as.integer(2);
>     cmsg <- as.character("Hi");
>     storage.mode(cfd) <- "integer";
>     storage.mode(cmsg) <- "character";
>     .Call("Rwrite",
>           fd=cfd,
>           msg=cmsg,
>           PACKAGE="forkex"
>        );
>   }
> 
> Upon running the above code as a call to `ptest()`, I receive a
> segmentation fault. Building the package as `R CMD check
> --use-valgrind ...` provides the following memcheck output:
> 
>> ptest();
> ==12591== Invalid read of size 1
> ==12591==    at 0x4D04209: SET_SYMVALUE (in /usr/lib64/R/lib/libR.so)
> ==12591==    by 0x4D01E51: Rf_ReplIteration (in /usr/lib64/R/lib/libR.so)
> ==12591==    by 0x4D020B7: (within /usr/lib64/R/lib/libR.so)
> ==12591==    by 0x4D027CF: run_Rmainloop (in /usr/lib64/R/lib/libR.so)
> ==12591==    by 0x40083A: main (in /usr/lib64/R/bin/exec/R)
> ==12591==  Address 0x9 is not stack'd, malloc'd or (recently)
free'd
> [2] Hi
>  *** caught segfault ***
> address 0x9, cause 'memory not mapped'
> aborting ...
> ==12591=> ==12591== ERROR SUMMARY: 1 errors from 1 contexts (suppressed:
18 from 1)
> ==12591== malloc/free: in use at exit: 22,564,238 bytes in 10,614 blocks.
> ==12591== malloc/free: 29,096 allocs, 18,482 frees, 44,702,479 bytes
allocated.
> ==12591== For counts of detected errors, rerun with: -v
> ==12591== searching for pointers to 10,614 not-freed blocks.
> ==12591== checked 19,665,464 bytes.
> ==12591=> ==12591== LEAK SUMMARY:
> ==12591==    definitely lost: 0 bytes in 0 blocks.
> ==12591==      possibly lost: 0 bytes in 0 blocks.
> ==12591==    still reachable: 22,564,238 bytes in 10,614 blocks.
> ==12591==         suppressed: 0 bytes in 0 blocks.
> ==12591== Rerun with --leak-check=full to see details of leaked memory.
> 
> The same segmentation fault occurs whether I try passing either the
> `int` or `character` or both (as in the above). I have not tried other
> types. However, I have attempted various type conversions in the
> Rdefines.h header, but cannot avoid the segmentation fault. This is
> the only code in the proof-of-concept pacakage (aside from useDynLoad
> related registration structures and the R_init_??? call).
> 
> I have a feeling it is something simple, but I am not well versed in R
> package development at this point. Please let me know if other
> information is helpful.
> 
> I am running Linux 2.6.27.30-170.2.82.fc10.x86_64 with R 2.10.0.
> 
> Thanks!
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

On Sun, Nov 15, 2009 at 2:52 PM, Duncan Murdoch - murdoch at stats.uwo.ca
<+nabble+miller_2555+1412c7fca2.murdoch#stats.uwo.ca at spamgourmet.com>
wrote:
> On 15/11/2009 1:41 PM, nabble.30.miller_2555 at spamgourmet.com wrote:
>>
> The "character" type in R corresponds to STRSXP in C, which is a
vector of
> CHARSXPs. ?So you need an extra step to get to the C string:
>
> const char * omsg = CHAR(STRING_ELT(msg, 0));
>
> Duncan Murdoch
>
Thank you for the suggestion. I have replaced the code as suggested,
but I had attempted this conversion earlier. Unfortunately, I still
receive the same segmentation fault (and backtrace). The underlying
problem no longer appears to relate to type conversion. The following
code represents the entirety of the extension's R and C code (and
NAMESPACE file), and still causes the segmentation fault:

NAMESPACE:
---------------------------------------------------
useDynLib("tstlib")
export( "ptest" )


ptest.R:
---------------------------------------------------
ptest <- function()  { .Call("Rwrite",
PACKAGE="tstlib");};


ptest.c:
---------------------------------------------------
#include <R.h>
void Rwrite() { printf("[%i] %s",12,"Hi"); }


ptest.R:
---------------------------------------------------
ptest <- function()  { .Call("Rwrite",
PACKAGE="tstlib");};


zzz.R:
---------------------------------------------------
.onLoad <- function(libname, pkgname)
{
}
.onUnload <- function(libpath) {
    library.dynam.unload("forkex", libpath)
  }


This is just about the most simple example I can think of, and don't
really know why it would segfault (if I change the interface in
ptest.R above from .Call to .C, no segfault occurs). The following is
the output from `R CMD SHLIB ptest.c`:

gcc -m64 -std=gnu99 -I/usr/include/R  -I/usr/local/include    -fpic
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c
ptest.c -o ptest.o
gcc -m64 -std=gnu99 -shared -L/usr/local/lib64 -o ptest.so ./ptest.o
-L/usr/lib64/R/lib -lR