[ESS] R session starts sending commands to wrong place

[Rodney Sparapani]

Ross Boylan wrote:
> Short version: I have an ess-remote session (under openMPI) and a
> regular R session.  Sometimes, typically after a long computation
> (hours) in the ess-remote session, commands entered in the ess-remote
> session get echoed to and executed by the regular R session.  The
> ess-remote session appears hung and unresponsive during this time.
> 
> I worked around this by quitting R in the *R* window, responding yes to
> several complaints about the R process disappearing, and then typing the
> commands in the ess-remote buffer.  This time, they stayed in the
> buffer.
> 
> Aside from not starting multiple R sessions, is there a good way to
> avoid this problem?  Is it a bug?
> 
> DETAILS
> 
> 11433 pts/4    S<s    0:00 /bin/sh
> 11530 pts/4    S<+    0:54  \_ emacs
> 14250 pts/0    S<s    0:00      \_ /bin/sh -i
> 30209 pts/0    S<+    0:00      |   \_ mpirun -np 32 --hostfile hosts
> RMPIInteractive
> 30014 pts/6    S<s+   0:09      \_ /usr/lib64/R/bin/exec/R --no-readline
> 
> 30214 ?        S<s    0:00 orted --bootproxy 1 --name 0.0.1 --num_procs
> 5 --vpid_start 0 --nodename n7 --universe ross at n7:default-universe-3
> 30215 ?        S<     0:00
> \_ /bin/bash /home/ross/clean/OLTData/RMPIInteractive
> 30219 ?        S<   141:09  |   \_ /usr/lib64/R/bin/exec/R --no-save
> 
> 30219 is the only R process not at 100% CPU, characteristic of openmpi
> slaves.  So presumably that is where the commands should be going.
> strace showed only
> 30219 15:49:37 read(0,  <unfinished ...>
> 
> I wonder if the cause is some interaction between ESS and openmpi, which
> does some input and output redirecting to wire one of the spawned
> processes (almost certainly 30219) to my "terminal".  My understanding
> is that ess-remote is simply sending commands to that terminal, and
> openmpi is taking care of getting them to the master R.
> 
> In even more detail:
> 1. start emacs
> 2. open shell within emacs
> 3. execute the mpirun command within the shell.
> 4. They invoked script does
>      R --no-save $*
>    for rank 0 and 
>      R --no-save $* > rmpi.$RANK 2>&1
>    for others.
> 5. In emacs, invoke ess-remote with language r.
> 6. In my terminal
> 	options(error=recover)
>    in an effort to avoid death at the first error.
>    It does that, but R's machinery still seems to think it's
> non-interactive.
> 7.  do long computation
> 8.  type a command, most commonly save.image()
> 9. hit enter.
> 10. cursor sits blinking on the "(" in save.image()
> 11. terminal non-responsive to inputs, mostly (in particular, hitting
> enter has no effect)
> 12.  hitting ctl-g seems to cause previous enters to print out, and
> better response to keys (at least I can switch to another session).
> 
> Variations:
> Step 8 is sometimes preceded by some commands executing successfully.
> It has hung up on commands involving no obvious disk I/O, e.g., print.
> This coupled, with sys admin check that the disk is OK, suggests it's
> not a disk problem.
> 
> The workspace (.RData) is around 13MB.  It's time stamp seems to match
> when I issued the save.image() command, but that is a save from the
> regular R process in the same directory.
> 
> I am not sure about the relative timing of launching the ess-remote
> process and the regular ess process.
> 
> Debian Lenny
> ess                           5.3.8~svn3917-1
> emacs                         22.2+2-5
> openmpi-bin                   1.2.7~rc2-2
> r-base-core                   2.7.1-1+lenny1
> 

Nice bug report.  However, I have no idea :o)  Can you upgrade these
packages to the latest version and still reproduce the bug?

Rodney