Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debugger stack shows incorrect line numbers after recover() #4917

Closed
profPlum opened this issue Jun 7, 2019 · 5 comments
Closed

Debugger stack shows incorrect line numbers after recover() #4917

profPlum opened this issue Jun 7, 2019 · 5 comments
Labels
bug stale Issues which have been closed automatically due to inactivitiy.

Comments

@profPlum
Copy link

@profPlum profPlum commented Jun 7, 2019

System details

RStudio Edition : Desktop
RStudio Version : 1.2.1335
OS Version      : macOS 10.14.4 (18E226)
R Version       : 3.6.0 (2019-04-26) -- "Planting of a Tree"

Steps to reproduce the problem

  1. rename bug-reproduce.txt -> bug-reproduce.R (example file given)
  2. source(bug-reproduce.R) # in Rstudio
  3. select frame 7 (though it could work with others?)
  4. look at line numbers in Traceback GUI display in Rstudio (some will be 0)

Describe the problem in detail

When Rstudio enters the debugger through a call to recover(), it doesn't always get the correct line information of the stack frames and instead just uses 0. This also prevents it from seeking (via double click) the line the stack was entered on; instead it just opens the file that the relevant code is in.

I don't know what triggers this bug because sometimes things work as expected, additionally it appears that it can affect only certain stack frames & is affected by code position somehow (??).

However even the where CLI debugger command (executed from within Rstudio console) will show you the correct line numbers (where they are available).

Describe the behavior you expected

I expected it to show/use the line numbers consistent with those shown from the where command & to seek to those lines properly (on click).

diagnostics-report.txt

Output from sessionInfo()

(from inside recovered() debugger session)):

R version 3.6.0 (2019-04-26)
Platform: x86_64-apple-darwin18.5.0 (64-bit)
Running under: macOS Mojave 10.14.4

Matrix products: default
BLAS: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
LAPACK: /usr/local/Cellar/openblas/0.3.6_1/lib/libopenblasp-r0.3.6.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats graphics grDevices utils datasets methods
[7] base

other attached packages:
[1] moments_0.14 ggplot2_3.1.1 dplyr_0.8.1 tidyr_0.8.3

loaded via a namespace (and not attached):
[1] Rcpp_1.0.1 withr_2.1.2 assertthat_0.2.1
[4] crayon_1.3.4 R6_2.4.0 grid_3.6.0
[7] plyr_1.8.4 gtable_0.3.0 magrittr_1.5
[10] scales_1.0.0 pillar_1.4.0 rlang_0.3.4
[13] lazyeval_0.2.2 rstudioapi_0.10 tools_3.6.0
[16] glue_1.3.1 purrr_0.3.2 munsell_0.5.0
[19] compiler_3.6.0 pkgconfig_2.0.2 colorspace_1.4-1

[22] tidyselect_0.2.5 tibble_2.1.1

@ronblum
Copy link
Contributor

@ronblum ronblum commented Jun 21, 2019

@profPlum Thank you for reporting this issue. I'm unable to reproduce it, though. Perhaps my file with an error isn't error-prone enough. Would you mind proviing:

  1. an example of the file you used to trigger the problem
  2. a screenshot of the problem

Thanks!

@profPlum
Copy link
Author

@profPlum profPlum commented Jul 4, 2019

@ronblum Hey thanks for the reply, turns out this bug is really situational. I gave you a script that can reproduce it now & updated the original post. Please take a look :)
P.S. Here is the screenshot:
Screen Shot 2019-07-03 at 9 47 54 PM

@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented Sep 3, 2019

Here's a slightly more minimal example:


options(error = recover)

bad <- function() {
  fails <- function() stop()
  fails()
  for (i in 1:10)
    fails()
}

bad()

If I source an R file with these contents, then enter the debugger, I see the wrong line numbers in the Traceback pane:

Screen Shot 2019-09-03 at 11 59 22 AM

It seems like the error is triggered if:

  1. You define an inline function that can throw an error;
  2. You call that function in multiple places in the function.

The debugger also seems to navigate frames incorrectly, highlighting the wrong bit of code as different frames are selected.

@jmcphers do you think this is something worth considering for v1.3?

@stale
Copy link

@stale stale bot commented Feb 6, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs, per https://github.com/rstudio/rstudio/wiki/Issue-Grooming. Thank you for your contributions.

@stale stale bot added the stale Issues which have been closed automatically due to inactivitiy. label Feb 6, 2021
@stale
Copy link

@stale stale bot commented Feb 20, 2021

This issue has been automatically closed due to inactivity.

@stale stale bot closed this as completed Feb 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug stale Issues which have been closed automatically due to inactivitiy.
Projects
None yet
Development

No branches or pull requests

3 participants