browser() behaviour different with ess-remote than otherwise

[aramirezreyes]

Hi!

My versions:
Emacs 29.1 (also observed it on 28) for macOS.
R 4.0.3 (linux)
Ess: 20230807.1422

I am observing that the browser exits apparently randomly and I cannot pinpoint all the situations but I here provide one. I guess this could be considered a support request as I assume it is something on my side, although it sounds similar to #1081 .

I log in into a remote computer via tramp. I then start a shel (M-x shell), launch R 4.0.3 and run M-x ess-remote.

Then I do this:

test1 <- function() {
  print("Entering function")
  a <- 1
  browser()
  b <- 2
  d <- a + b
  return("Exiting function")
}

test1()

If then do the following sequence on the shell containing the R process I observe:

> test1()
[1] "Entering function"
Called from: test1()
Browse[1]> a
[1] 1
Browse[2]> b
[1] 2
Browse[2]> d
[1] 3
Browse[2]> d
Error: object 'd' not found
> 

First, the browser went down one level, and then it exited on an error.

When launching R from my terminal without involving emacs, I observe the following:

test1 <- function() {
   print("Entering function")
   a <- 1
   browser()
   b <- 2
   d <- a + b
   return("Exiting function")
 }
> test1()
[1] "Entering function"
Called from: test1()
Browse[1]> a
[1] 1
Browse[1]> b
Error in test1() : object 'b' not found
Browse[1]> d
Error in test1() : object 'd' not found
Browse[1]> d
Error in test1() : object 'd' not found
Browse[1]> 

So the browser does not descend into Browse[2], nor it exits on error, so it seems to be more resilient. Is there something I am doing wrong?

[lionel-]

ESS tracebug automatically calls n in the background, which explains the [2] suffix.

However it should only do this once, so b should not be defined at that point. Here is what I get when I do the same sequence in ESS locally (no tramp):

test1()
[1] "Entering function"
Called from: test1()
Browse[1]> debug at #5: b <- 2
Browse[2]> a
[1] 1
Browse[2]> a
[1] 1
Browse[2]> b
Error in test1() (from #5) : object 'b' not found
Browse[2]> d
Error in test1() (from #5) : object 'd' not found
Browse[2]> d
Error in test1() (from #5) : object 'd' not found
Browse[2]> 

There may be a bug in the interaction between ess-remote and ess-tracebug.

[aramirezreyes]

I should have done my due diligence and try it locally! I can confirm I can reproduce your sequence without going through tramp/ssh/ess-remote.

[aramirezreyes]

Coming back to this, I noticed that when attaching a process via ess-remote, ess-tracebug is not enabled. Which causes the problem.

Disabling ess-tracebug on a local session, reproduces the weird behavior.

Should ess-remote try to enable ess-tracebug? If so (which I think it should, as it would give a consistent experience) it would be fixed by the third part of #1182