2013-03-02 7 views
2

J'ai codé quelques simulations en utilisant inline/RcppArmadillo et j'ai trébuché sur un problème avec RNGScope. Est-ce un bug ou suis-je en train de faire quelque chose de vraiment stupide? J'ai vidé la fonction pour la rendre lisible (voir ci-dessous).Erreur de segmentation RNGscope

Cheers, Ed

library(inline) 
code_cpp <- ' 
using namespace arma; 
// From R 
uvec    x0 = as<uvec>(x0_r); 
vec   time_vec = as<vec>(time_vec_r); 
// Declare variables 
umat  simulation_data=zeros<umat>(x0.n_elem, time_vec.n_elem); 
RNGScope scope; 
return wrap(simulation_data); 
' 

gillespie_sim <- cxxfunction(body = code_cpp, 
           sig = signature(x0_r = "integer", time_vec_r= "numeric"), 
         plugin = "RcppArmadillo") 


x0 <- c(1,0,0,0,0,0) 
time_vec <- 1:800 
set.seed(23) 
for(i in 1:100000) out2 <- gillespie_sim(x0_r=x0,time_vec_r=time_vec) 

L'erreur que je reçois

R (43305) malloc: * erreur pour objet 0x108c30a00: contrôle incorrect pour objet libéré - objet a probablement été modifié après avoir été libéré. * mis un point d'arrêt dans malloc_error_break pour déboguer piège Abandonner: 6

Répondre

0

Hm, je vois deux problèmes:

a) Vous utilisez umat, mais on n'a pas unsigned int dans R, donc cela obtiendrez beaucoup de copies très inefficaces. Je l'ai changé à mat, mais imat devrait fonctionner aussi. B) Vous bouclez un lot avec for(i in 1:100000). Nous avons vu un problème similaire avec des "gazillions" de créations d'objets. Nous ne savons pas où est le bogue.

Avec un N plus petit, cela ne semble pas se produire (comme souvent). Nous allons jeter un oeil et voir si RNGScope a quelque chose à voir avec ça - mais c'est un objet très simple.

Merci pour le rapport de bogue. Pensez à utiliser rcpp-devel la prochaine fois, s'il vous plaît.

Modifier: Notez également que lors de l'utilisation Rcpp vecteurs, l'erreur ne semble pas se manifester. Vous pouvez donc utiliser la méthode en deux étapes de la première initialisation des objets Rcpp puis de l'initialisation des objets Armadillo: le fichier fastLm.r dans le package en a un exemple.

suppressMessages(library(Rcpp)) 
suppressMessages(library(inline)) 

useRcpp <- function() { 
    code_cpp <- ' 
// From R 
NumericVector x0(x0_r); 
NumericVector time_vec(time_vec_r); 
// Declare variables 
NumericMatrix simulation_data(x0.size(), time_vec.size()); 
RNGScope scope; 
return simulation_data; 
' 

cxxfunction(body = code_cpp, 
      sig = signature(x0_r = "integer", time_vec_r= "numeric"), 
      plugin = "Rcpp") 
} 

gillespie_sim <- useRcpp() 

x0 <- c(1,0,0,0,0,0) 
time_vec <- 1:800 
set.seed(23) 
for(i in 1:100000) out2 <- gillespie_sim(x0_r=x0,time_vec_r=time_vec) 
cat("Done\n") 
+0

Merci pour la réponse rapide. Je ne sais pas si ça aide, mais si je commente RNGScope et ajoute le GetRNGstate(); PutRNGstate(); Je n'ai plus l'erreur. J'ai pris note de rcpp-devel. Merci, Ed – user2127594

+0

C'est un bon suivi. Mais regardez notre classe RNGScope - c'est aussi simple que possible. Pourquoi cela irait-il mal? –

+1

Oui, c'est juste un moyen intelligent de simplifier les choses RNGstate. Cela ne devrait pas poser de problème. Malheureusement, ma connaissance du C++ est mince, donc je ne sais pas pourquoi ça pourrait tout bousiller. Sur une autre note, pour une raison quelconque, si j'échange l'enveloppe de retour (simulation_data); pour renvoyer un retour de nombre entier (22); il arrête également de s'écraser. Ed – user2127594