core dump if draw a graph and `dev.off()` at the same line with `ggplot2` about rcall.jl

[dmbates]

Right now I can't even get as far as plotting. I am also using R version 3.1.2 and I get

julia> "pdf(file='/tmp/tt.pdf'); plot(x,y,type='l');dev.off()" |> reval
Error in plot.new() : the base graphics system is not registered

[panlanfeng]

The base graphics system works pretty well on my Ubuntu 14.04 and also on a Redhat server.
This might be OS dependent.

[simonbyrne]

I'm seeing the same problem as @dmbates (I'm on OS X). This seems a bit odd, but if I modify this line by changing Rembed to R, then the following works

using RCall
"pdf(file='/tmp/plt1.pdf')" |> rprint
"plot(1:10)" |> rprint
"dev.off()" |> rprint

after that, I can also use

"pdf(file='/tmp/plt2.pdf'); plot(1:10,(1:10)^2); dev.off()" |> rprint

without any problems. But, if I try it straight off the bat,

julia> using RCall

julia> "pdf(file='/tmp/plt2.pdf'); plot(1:10,(1:10)^2); dev.off()" |> rprint

signal (11): Segmentation fault: 11
sexp at /Users/simon/.julia/v0.3/RCall/src/sexp.jl:18
reval at /Users/simon/.julia/v0.3/RCall/src/iface.jl:11
reval at /Users/simon/.julia/v0.3/RCall/src/iface.jl:16
jl_apply at /Users/vagrant/buildbot/slave/package_osx10_9/build/src/gf.c:1418
rprint at /Users/simon/.julia/v0.3/RCall/src/iface.jl:32
jlcall_rprint_20749 at  (unknown line)
jl_apply at /Users/vagrant/buildbot/slave/package_osx10_9/build/src/gf.c:1418
|> at operators.jl:178
jl_apply at /Users/vagrant/buildbot/slave/package_osx10_9/build/src/gf.c:1418
jl_apply at /Users/vagrant/buildbot/slave/package_osx10_9/build/src/interpreter.c:59
eval at /Users/vagrant/buildbot/slave/package_osx10_9/build/src/interpreter.c:207
jl_toplevel_eval_flex at /Users/vagrant/buildbot/slave/package_osx10_9/build/src/toplevel.c:496
jl_f_top_eval at /Users/vagrant/buildbot/slave/package_osx10_9/build/src/builtins.c:399
eval_user_input at REPL.jl:53
jlcall_eval_user_input_20177 at  (unknown line)
jl_apply at /Users/vagrant/buildbot/slave/package_osx10_9/build/src/./julia.h:982
anonymous at task.jl:95
jl_apply at /Users/vagrant/buildbot/slave/package_osx10_9/build/src/task.c:423
julia_trampoline at /Users/vagrant/buildbot/slave/package_osx10_9/build/src/init.c:1032

 *** caught segfault ***
address 0x7fa700000000, cause 'memory not mapped'

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace

My version info:

julia> versioninfo()
Julia Version 0.3.7
Commit cb9bcae (2015-03-23 21:36 UTC)
Platform Info:
  System: Darwin (x86_64-apple-darwin13.4.0)
  CPU: Intel(R) Core(TM) i7-2677M CPU @ 1.80GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

[simonbyrne]

Okay, this is getting even more strange.

I was trying to get this to play nice with IJulia, but something weird is happening. I save the output to a temporary png file:

rprint("png('/tmp/aa.png')")
rprint("plot(1:10)")
rprint("dev.off()")

which works fine (and can be re-run at this stage without any problems). Then I try to load the file using imread from Images.jl (which itself works fine), but if I now re-run the above sequence, the second line throws:

Error in plot.new() : the base graphics system is not registered
Error occurred in R_tryEval
while loading In[8], in expression starting on line 1

 in reval at /Users/simon/.julia/v0.3/RCall/src/iface.jl:5
 in reval at /Users/simon/.julia/v0.3/RCall/src/iface.jl:12
 in reval at /Users/simon/.julia/v0.3/RCall/src/iface.jl:16
 in rprint at /Users/simon/.julia/v0.3/RCall/src/iface.jl:32

Any thoughts why this might be happening? I noticed Images.jl uses some OS X specific functionality, which may be causing conflicts somewhere. @timholy any suggestions for where I might look?

[panlanfeng]

Right now (RCall 0.2.0) every other works fine except

"""pdf();print(ggplot()+geom_line(aes(x=x, y=y)));dev.off()""" |> rprint

still causes a core dump.
But print is not necessary so this issue can be closed.

[randy3k]

@panlanfeng,
it was due to a memory leak and should be fixed by 5f54e20.

[panlanfeng]

No more core dump.
Thanks for the fix!