Discussion:
[R-SIG-Mac] Unload CRAN package and locally built package
Gábor Csárdi
2014-09-25 15:27:06 UTC
Permalink
Hi all,

I have a little mystery here, and ideas would be welcome.

I would like to unload the package igraph. The following works fine
with the package downloaded from CRAN (Snow Leopard package):

install.packages("igraph")
library(igraph)
library(devtools)
unload(inst("igraph"))

However, if I build the package myself on my machine, then it does not
work any more and unloading hangs. I can press CTRL+C to get the R
prompt back, but every command hangs again. This is my machine:

~$ xcodebuild -version
Xcode 5.1.1
Build version 5B1008

~$ Rscript -e 'sessionInfo()'
R version 3.1.1 (2014-07-10)
Platform: x86_64-apple-darwin10.8.0 (64-bit)

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats graphics grDevices utils datasets base

It also hangs if I call dyn.unload() directly, instead of calling
devtools; if I remove
the igraph.so file from the package, then it works again, so it is
definitely something with the .so file.

I know this is not much work with, but if you have any guesses, please
let me know. Thanks,
Gabor
Simon Urbanek
2014-09-26 02:53:40 UTC
Permalink
Gabor,

what OS X version are you using? More recent OS X versions have slightly different C++ ABI so you can't really mix C++ code compiled on SL and let's say Mavericks - hence the two different sets of binaries. That would be my guess here since igraph uses C++ and it involves destructor code on unloading...

Cheers,
Simon
Post by Gábor Csárdi
Hi all,
I have a little mystery here, and ideas would be welcome.
I would like to unload the package igraph. The following works fine
install.packages("igraph")
library(igraph)
library(devtools)
unload(inst("igraph"))
However, if I build the package myself on my machine, then it does not
work any more and unloading hangs. I can press CTRL+C to get the R
~$ xcodebuild -version
Xcode 5.1.1
Build version 5B1008
~$ Rscript -e 'sessionInfo()'
R version 3.1.1 (2014-07-10)
Platform: x86_64-apple-darwin10.8.0 (64-bit)
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
[1] stats graphics grDevices utils datasets base
It also hangs if I call dyn.unload() directly, instead of calling
devtools; if I remove
the igraph.so file from the package, then it works again, so it is
definitely something with the .so file.
I know this is not much work with, but if you have any guesses, please
let me know. Thanks,
Gabor
_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac at r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Gábor Csárdi
2014-09-26 08:40:22 UTC
Permalink
Hi Simon,

thanks for the answer, sorry, I should have included this, it is
apparently not in sessionInfo().

So, this happens on 10.9.4 with R 3.1.1 and also on 10.8.5 with R
3.1.0. And the (10.8) CRAN binary version of igraph unloads cleanly on
both of them.

I am not sure how and why destructors would be called when unloading,
igraph does not use any external pointers to keep C++ objects alive.
They should be destroyed when returning the C/C++ call to R. It is
certainly possible that they are not, because of a bug or something,
but I cannot even unload if I do not call any igraph functions at all,
just load the package. (Loading the package calls an igraph_init, but
that only sets some global variables, it does not create any C or C++
objects.)

But I definitely think that you are right in general, and this is some
binary incompatibility between the R binary and my binary. It has been
a long standing issue, actually. It never worked for me in the last ~5
years.

I am also not really sure how to debug this, but will check with an R
version compiled on my mac in a minute.

Thank again, Best,
Gabor

On Thu, Sep 25, 2014 at 10:53 PM, Simon Urbanek
Post by Simon Urbanek
Gabor,
what OS X version are you using? More recent OS X versions have slightly different C++ ABI so you can't really mix C++ code compiled on SL and let's say Mavericks - hence the two different sets of binaries. That would be my guess here since igraph uses C++ and it involves destructor code on unloading...
Cheers,
Simon
Post by Gábor Csárdi
Hi all,
I have a little mystery here, and ideas would be welcome.
I would like to unload the package igraph. The following works fine
install.packages("igraph")
library(igraph)
library(devtools)
unload(inst("igraph"))
However, if I build the package myself on my machine, then it does not
work any more and unloading hangs. I can press CTRL+C to get the R
~$ xcodebuild -version
Xcode 5.1.1
Build version 5B1008
~$ Rscript -e 'sessionInfo()'
R version 3.1.1 (2014-07-10)
Platform: x86_64-apple-darwin10.8.0 (64-bit)
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
[1] stats graphics grDevices utils datasets base
It also hangs if I call dyn.unload() directly, instead of calling
devtools; if I remove
the igraph.so file from the package, then it works again, so it is
definitely something with the .so file.
I know this is not much work with, but if you have any guesses, please
let me know. Thanks,
Gabor
_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac at r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Gábor Csárdi
2014-09-26 09:56:01 UTC
Permalink
I just tried on an R version that I compiled myself, and unloading
works fine. \o/

I also tried using the Mavericks build of R, and that works fine, too,
on my Mavericks laptop. \o/

I have no idea why the Snow Leopard R build did not work with my other
Snow Leopard machine, but honestly, I don't care much about it. :)

Thanks for the help, this is already a great day, and it is only 5:50am! :)

Best,
Gabor
Post by Gábor Csárdi
Hi Simon,
thanks for the answer, sorry, I should have included this, it is
apparently not in sessionInfo().
So, this happens on 10.9.4 with R 3.1.1 and also on 10.8.5 with R
3.1.0. And the (10.8) CRAN binary version of igraph unloads cleanly on
both of them.
I am not sure how and why destructors would be called when unloading,
igraph does not use any external pointers to keep C++ objects alive.
They should be destroyed when returning the C/C++ call to R. It is
certainly possible that they are not, because of a bug or something,
but I cannot even unload if I do not call any igraph functions at all,
just load the package. (Loading the package calls an igraph_init, but
that only sets some global variables, it does not create any C or C++
objects.)
But I definitely think that you are right in general, and this is some
binary incompatibility between the R binary and my binary. It has been
a long standing issue, actually. It never worked for me in the last ~5
years.
I am also not really sure how to debug this, but will check with an R
version compiled on my mac in a minute.
Thank again, Best,
Gabor
On Thu, Sep 25, 2014 at 10:53 PM, Simon Urbanek
Post by Simon Urbanek
Gabor,
what OS X version are you using? More recent OS X versions have slightly different C++ ABI so you can't really mix C++ code compiled on SL and let's say Mavericks - hence the two different sets of binaries. That would be my guess here since igraph uses C++ and it involves destructor code on unloading...
Cheers,
Simon
Post by Gábor Csárdi
Hi all,
I have a little mystery here, and ideas would be welcome.
I would like to unload the package igraph. The following works fine
install.packages("igraph")
library(igraph)
library(devtools)
unload(inst("igraph"))
However, if I build the package myself on my machine, then it does not
work any more and unloading hangs. I can press CTRL+C to get the R
~$ xcodebuild -version
Xcode 5.1.1
Build version 5B1008
~$ Rscript -e 'sessionInfo()'
R version 3.1.1 (2014-07-10)
Platform: x86_64-apple-darwin10.8.0 (64-bit)
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
[1] stats graphics grDevices utils datasets base
It also hangs if I call dyn.unload() directly, instead of calling
devtools; if I remove
the igraph.so file from the package, then it works again, so it is
definitely something with the .so file.
I know this is not much work with, but if you have any guesses, please
let me know. Thanks,
Gabor
_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac at r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Loading...