Bug 15770 - While in browse environment entered from Step Into, every function call is debugged
Summary: While in browse environment entered from Step Into, every function call is de...
Status: CLOSED FIXED
Alias: None
Product: R
Classification: Unclassified
Component: Low-level (show other bugs)
Version: R 3.1.0
Hardware: All OS X Mavericks
: P5 normal
Assignee: R-core
URL:
Depends on:
Blocks:
 
Reported: 2014-04-21 19:19 UTC by Jonathan
Modified: 2014-04-22 09:56 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan 2014-04-21 19:19:45 UTC
Repro: 

1) Create a couple of functions:

> foo <- function() { cat("123") }
> bar <- function() { browser(); foo() }

2) Invoke one and step into the other:

> bar()
Called from: bar()
Browse[1]> n
debug at #1: foo()
Browse[2]> s
debugging in: foo()
debug at #1: {
    cat("123")
}

3) Call any R function from the resulting browse prompt. The function will be debugged rather than being run. 

Browse[3]> print("abc")
debugging in: print("abc")
Comment 1 Peter Dalgaard 2014-04-21 19:43:37 UTC
Isn't that a feature? I can vaguely imagine scenarios where you'd actually want to step into functions that are only available once you are in the browser.

You can just type 'c' or 'f' and be gone with it.
Comment 2 Jonathan 2014-04-21 20:05:48 UTC
I think the intent of "s" is to just step into the next call (i.e. foo() in this example). It seems odd that it affects not only the call you stepped into but every call after it.

In addition, it makes it difficult to introspect the environment of the function you've just stepped into--ls(), print(), recover(), etc. don't work as you'd expect. 

Finally, even if the behavior is desirable, it isn't consistent. 

Browse[3]> print("abc")
debugging in: print("abc")
debug: UseMethod("print")
Browse[5]> f
[1] "abc"
Browse[3]> print("abc")
[1] "abc"

Perhaps I'm just confused about the model here--to me "step into" means "step into the very next function call", whereas here it seems to mean "debug every function call until any function finishes running". Is that the desired behavior?
Comment 3 Jonathan 2014-04-21 20:53:56 UTC
To be more precise, it appears that the current behavior of "s" is to debug every function call until you use another browser command ("n", "f", etc). I think this is the code responsible:

https://github.com/wch/r-source/blob/fc57ff20c73dbea0f76b6825e5e85bd6c052f764/src/main/eval.c#L978-L979
Comment 4 Duncan Murdoch 2014-04-22 09:56:47 UTC
Fixed in R-devel and soon in R-patched.  

The intent is that <CR> repeats the previous command, whether n or s or f.  s should not have applied to the expression evaluated in the browser.  Use debug() or debugonce() if you want to debug some other expression.