invalid ELF header

[William Wolf]

I'm trying to deploy an application that uses an R package that I built. This package lives on GitHub, and contains a shared object (*.so). This shared object was created via compiling some C++ code locally. I compiled this code in a Docker container such that it's operating system (Linux Ubuntu) would match that of shinyapps. I continue to run into the following error, which I understand suggests that the shared object was built on an operating system different than that of the destination server (shinyapps in this case).

Error in dyn.load(file, DLLpath = DLLpath, ...) : 

  unable to load shared object '/usr/local/lib/R/site-library/RescueTimeEstimator/libs/RescueTimeEstimator.so':

  /usr/local/lib/R/site-library/RescueTimeEstimator/libs/RescueTimeEstimator.so: invalid ELF header

Thoughts? Thanks.

[Joshua Spiewak]

My guess is that it is because the OS/ABI of your file is GNU/Linux and it needs to be SYSV.

It might be easier to allow the package to be compiled by shinyapps.io itself, instead of committing the binary to the package itself.

[William Wolf]

Hey Joshua - thanks for the speedy response.

The code itself contains an RStan model which is compiled when it is first run. This compilation was taking place on your server yet giving the following error: 

Compilation ERROR, function(s)/method(s) not created! In file included from /usr/local/lib/R/site-library/BH/include/boost/config.hpp:39:0,

                 from /usr/local/lib/R/site-library/BH/include/boost/math/tools/config.hpp:13,

                 from /usr/local/lib/R/site-library/StanHeaders/include/stan/math/rev/core/var.hpp:7,

                 from /usr/local/lib/R/site-library/StanHeaders/include/stan/math/rev/core/gevv_vvv_vari.hpp:5,

                 from /usr/local/lib/R/site-library/StanHeaders/include/stan/math/rev/core.hpp:12,

                 from /usr/local/lib/R/site-library/StanHeaders/include/stan/math/rev/mat.hpp:4,

                 from /usr/local/lib/R/site-library/StanHeaders/include/stan/math.hpp:4,

                 from /usr/local/lib/R/site-library/StanHeaders/include/src/stan/model/model_header.hpp:4,

                 from file137729fa09.cpp:8:

/usr/local/lib/R/site-library/BH/include/boost/config/compiler/gcc.hpp:186:0: warning: "BOOST_NO_CXX11_RVALUE_REFERENCES" redefined [enabled by default]

 #  define BOOST_NO_CXX11_RVALUE_REFERENCES

 ^

<command-line>:0:0: note: this is the location of the previous definition

g++: internal compiler error: Killed (program cc1plus)

Please submit a full bug report,

with preprocessed source if appropriate.

See <file:///usr/share/doc/gcc-4.8/README.Bugs> for instructions.

make: *** [file137729fa09.o] Error 4

My guess was that this was a memory error. In addition, because the g++ compiler is being used instead of clang++ (as on my Mac, where it compiles successfully), I asked the initial question.

In solution, the Stan devs recommended I build this model into a package of its own, then include that package as a dependency for my project. Therein, the RStan model is pre-compiled (what I had done on the Docker container) and then sent to GitHub. This approach is what is giving the error in the original post in this thread.

What do you suggest?

[Joshua Spiewak]

What does your Dockerfile look like?

shinyapps.io currently runs Ubuntu 14.04, but I am not sure what would account for the difference in OS/ABI.

[William Wolf]

I'm using the rocker/rstudio image. I start the container interactively, then once inside:

1. Download require packages via `R --vanilla --slave -f packrat/init.R --args --bootstrap-packrat`
2. (Intrinsically) compile the RStan code via: `R CMD INSTALL -l RescueTimeEstimator/packrat/lib/x86_64-pc-linux-gnu/3.3.2/ --no-multiarch --with-keep.source RescueTimeEstimator `. This worked locally on my Mac (I could thereafter load the module into RStudio and use the code without the model recompiling when first-called, as intended.
   
3. Push to master on GitHub. I leave the 2 files that the compile step built - `RescueTimeEstimator.so` and `Module.o` - in the `src` directory. (This is correct, yeah?)
4. Push all assets from within RStudio to shinyapps and receive the above error.

For reference, the code for this project is here. Continued thanks.

[Joshua Spiewak]

Looks to me like rocker bases their images off of Debian Jessie, which could account for the difference.

[William Wolf]

Ah yes. I'll try with an Ubuntu image and report back.

[William Wolf]

Joshua,

I just compiled the code on the following Docker image which uses Ubuntu 14.04. I've received the same error during deploy. What should I try next?

[2017-02-08T11:31:43.561992132+0000] Building R package: RescueTimeEstimator (1.0)

/mnt/packages/build /mnt

Warning in untar2(tarfile, files, list, exdir, restore_times) :

  skipping pax global extended headers

* installing to library ‘/usr/local/lib/R/site-library’

* installing *source* package ‘RescueTimeEstimator’ ...

** libs

make: Nothing to be done for `all'.

installing to /usr/local/lib/R/site-library/RescueTimeEstimator/libs

** R

** exec

** inst

** preparing package for lazy loading

** help

Warning: /tmp/RtmpGMooVQ/R.INSTALL1b714c2042c/cavaunpeu-RescueTimeEstimator-aa89703/man/RescueTimeEstimator-package.Rd:26: All text must be in a section

Warning: /tmp/RtmpGMooVQ/R.INSTALL1b714c2042c/cavaunpeu-RescueTimeEstimator-aa89703/man/RescueTimeEstimator-package.Rd:27: All text must be in a section

*** installing help indices

** building package indices

** testing if installed package can be loaded

Error in dyn.load(file, DLLpath = DLLpath, ...) : 

  unable to load shared object '/usr/local/lib/R/site-library/RescueTimeEstimator/libs/RescueTimeEstimator.so':

  /usr/local/lib/R/site-library/RescueTimeEstimator/libs/RescueTimeEstimator.so: invalid ELF header

[Joshua Spiewak]

Not sure, but whatever you are doing to compile is still creating with the wrong ABI:

jss@node3:/tmp/RescueTimeEstimator/src$ file /lib/x86_64-linux-gnu/libc-2.19.so
/lib/x86_64-linux-gnu/libc-2.19.so: ELF 64-bit LSB  shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), BuildID[sha1]=cf699a15caae64f50311fc4655b86dc39a479789, for GNU/Linux 2.6.24, stripped
jss@node3:/tmp/RescueTimeEstimator/src$ file RescueTimeEstimator.so
RescueTimeEstimator.so: ELF 64-bit LSB  shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=f172c810d410f3afe4f5ff201bb386b04babd332, not stripped

I tweaked it by hand:

jss@node3:/tmp/RescueTimeEstimator/src$ elfedit --output-osabi none RescueTimeEstimator.so
jss@node3:/tmp/RescueTimeEstimator/src$ file RescueTimeEstimator.so
RescueTimeEstimator.so: ELF 64-bit LSB  shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=f172c810d410f3afe4f5ff201bb386b04babd332, not stripped

So at least that might be a way of eliminating that oddity as the cause.

[William Wolf]

I just made that change on my end, pushed [RescueTimeEstimator] to master, re-deployed from RStudio and received the same error.

Perhaps you could glance at the project code to see if anything looks grossly misplaced? It's short, and builds/installs no problem on my local machine. The project skeleton was built with the `rstan_package_skeleton` function from the `rstantools` module.

[William Wolf]

Also, must I uncheck the "rebuild from cache" at each redeploy [for packages being installed from GitHub]?

--
You received this message because you are subscribed to a topic in the Google Groups "shinyapps.io Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/shinyapps-users/hzmzb_jnoAA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to shinyapps-use...@googlegroups.com.
To post to this group, send email to shinyap...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/shinyapps-users/346d4ad5-6fde-4f6b-b455-ef818d6f0d20%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

William Wolf

Studying things @ OSMLM

Blogs: Data; Travel

[Joshua Spiewak]

I am no expert on packages or packrat.

Is it possible that the .so inside of the packrat bundle that is checked in is actually what is getting used?

Are you able to install your package, from GitHub, on a separate Docker container using the same image as you compiled on?

[Joshua Spiewak]

The package cache is enabled or disabled as a setting on the application. If you have it disabled, and you update the package in GitHub and re-deploy, it should be picked up.

Once things are working with the package, you might re-enable the cache so your application deploys are faster.

To unsubscribe from this group and all its topics, send an email to shinyapps-users+unsubscribe@googlegroups.com.
To post to this group, send email to shinyapps-users@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/shinyapps-users/346d4ad5-6fde-4f6b-b455-ef818d6f0d20%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[William Wolf]

Joshua,

In working with the Stan developers, they made changes to my project (so as to conform it to the way they do things). Furthermore, they recommended I install the package [on the shinyapps server] using the `args = --preclean` flag as is done in rstanarm. The results are as follows:

With both `src/RescueTimeEstimator.so` and `src/Modules.o` omitted from the project, I am able to successfully install and run the package on a fresh Docker container running Ubuntu 14.04 (dmccloskey/r-base image).

Additionally, this works for both: 

• `install_github("cavaunpeu/RescueTimeEstimator", args = "--preclean", build_vignettes = FALSE)`
  
• `install_github("cavaunpeu/RescueTimeEstimator")`
  

Unfortunately, when I deploy to shinyapps, I get the same errors as before.

• With the cache off, I get a message saying `Error: Unhandled Exception: Child Task 340213605 failed: Error building image: Error building RescueTimeEstimator (1.0)`, and nothing more.
  
• Subsequently, with the cache then turned on, I get the same ELF header error as before.
  

I've attached both logs.

Crucially, with both `src/RescueTimeEstimator.so` and `src/Modules.o` now omitted from the project, the shinyapps server is tasked with two things:

1. Compiling the RStan code
   
2. Building the package
   

In my initial attempt a week ago - where I simply included the RStan code in my application project, and didn't build a separate R package as I'm doing now - the server was tasked with #1 just the same, and failed (presumably) because of a simple memory error. In fact, this is probably the simple reason the GitHub install is failing as well.

In all, I see 3 possible routes to get this thing to work:

1. Leave the Stan code in the application repository. This implies:
1. I would not make a separate R package to contain this Stan code, as I'm doing now (`cavaunpeu/RescueTimeEstimator`).
2. When the Stan model is first run on the shinyapps server, it must be compiled by g++. This is what I tried in my initial attempt, and it failed for (presumably) a simple memory error.
2. Compile the Stan code in a Docker container running Ubuntu 14.04, then include the resulting `src/RescueTimeEstimator.so` and `src/Modules.o` in the GitHub repository. Results:
1. This resulted in "ELF header" errors on the shinyapps server, including after using the `elfedit` tool you recommended above.
2. On a fresh Docker container running Ubuntu 14.04, I can successfully install from GitHub using both:
1. `install_github("cavaunpeu/RescueTimeEstimator", args = "--preclean", build_vignettes = FALSE)`
2. `install_github("cavaunpeu/RescueTimeEstimator")`
3. Create an R package containing the Stan model, which is tasked at deploy with both compiling the Stan model in g++ then building the R package. Results:
1. As shown above. Solution: more memory.

In the first and third cases, the solution seems to simply be to acquire more memory. This said, I'd only need this memory for the 3 minutes it takes the model code to initial compile. Thereafter, the 1GB free-tier is more than sufficient. Of course, I could upgrade to a paid plan, but $40/month for a 3-minute use-case is out of my budget. :/

How do you recommend I proceed?

Continued thanks.

P.S. For reference, the related thread on the Stan forums can be found here.

To unsubscribe from this group and all its topics, send an email to shinyapps-use...@googlegroups.com.
To post to this group, send email to shinyap...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/shinyapps-users/346d4ad5-6fde-4f6b-b455-ef818d6f0d20%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Joshua Spiewak]

Per my earlier comment about not being packrat expert, you still have a bundle in the packrat subdirectory that contains the .so file built on the Mac.

The full logs for building RescueTimeEstimator are:

[2017-02-09T09:56:51.374894057+0000] Building R package: RescueTimeEstimator (1.0)

/mnt/packages/build /mnt
Warning in untar2(tarfile, files, list, exdir, restore_times) :
  skipping pax global extended headers
* installing to library ‘/usr/local/lib/R/site-library’
* installing *source* package ‘RescueTimeEstimator’ ...
** libs
make: Nothing to be done for

`all'.

installing to /usr/local/lib/R/site-library/RescueTimeEstimator/libs
** R
** exec
** inst
** preparing package for lazy loading
** help

Warning: /tmp/Rtmp78PKyP/R.INSTALLa32e3a6d6/cavaunpeu-RescueTimeEstimator-aa89703/man/RescueTimeEstimator-package.Rd:26: All text must be in a section
Warning: /tmp/Rtmp78PKyP/R.INSTALLa32e3a6d6/cavaunpeu-RescueTimeEstimator-aa89703/man/RescueTimeEstimator-package.Rd:27: All text must be in a section

*** installing help indices
** building package indices
** testing if installed package can be loaded
Error in dyn.load(file, DLLpath = DLLpath, ...) :
  unable to load shared object '/usr/local/lib/R/site-library/RescueTimeEstimator/libs/RescueTimeEstimator.so':
  /usr/local/lib/R/site-library/RescueTimeEstimator/libs/RescueTimeEstimator.so: invalid ELF header

Error: loading failed
Execution halted
ERROR: loading failed
* removing ‘/usr/local/lib/R/site-library/RescueTimeEstimator’

Given that it found nothing to do, I looked at what was actually downloaded from GitHub to build (for the task you mentioned, 340213605):

Downloading package from: https://codeload.github.com/cavaunpeu/RescueTimeEstimator/legacy.tar.gz/aa89703822250864c9da3240af44f9aa96428e8b

That would appear to have the RescueTimeEstimator.so and Modules.o files.

The giveaway here is the last part of the path, which is the Git sha indicating the commit, which is your initial commit.

While you do not need to bump the version every time, the particular commit installed locally is used when uploading your application to shinyapps.io to make sure we are using the same version as what you have locally. If you change your package on GitHub, you need to install it locally before deploying the application.

[William Wolf]

That did it! This was not obvious to me: I was diligently pushing all updates to GitHub/master, as I figured that's where devtools::install_github pulls from.

1. As a post-mortem, was there any way for me to have verified what commit was being used?
   
2. For others with a similar problem, the `RescueTimeEstimator.so` and `Modules.o` files should not be included on GitHub. (These are the files that are generated when the Stan code is compiled into C++ code, but before the encompassing R package itself is built).

Thanks so much for your help. Here's the app! (I still need to make a few tweaks, so it might be down when you go to check, heh.)

[Joshua Spiewak]

Awesome!

devtools::install_github installs the package once, it doesn't automatically notice updates, and rsconnect always captures the version you have locally, and shinyapps.io will use that version.

devtools::session_info will display the SHA of what is currently installed.