I have some code running fine at R console, but crashes the R session in Rstudio. I wonder if it is possible to attach gdb to the r session in rstudio for trouble shooting?
Related
I'm trying to debug a gtk program by attaching it to gdb debugger but when I did the, gtk app freeze unless I execute next instruction or continue the program. It's annoying. I tried using ltrace but it is fill with gtk functions. How am I gonna debug this?
I'm working on an R package, bigKRLS. bigKRLS works on Windows RGui but encounters a fatal error on Windows RStudio. Some details...
Windows RGui works but Windows RStudio encounters a fatal error; confirmed on four different machines using R 3.3.0, 3.3.1, 3.3.3; RTools 3.3 and 3.4 following the best practices recommended by the Coatless Professor; RStudio 1.0.136; Windows 7 and 8. Presently, bigKRLS works on RStudio for Mac OS X Yosemite and Ubuntu 14.04 without issue.
bigKRLS depends on bigmemory, Rcpp, RcppArmadillo, and snow (but the problem pre-dates the recent addition of snow, which can be disabled for testing purposes by setting bigKRLS(..., Ncores = 1)).
devtools::install_github('rdrr1990/bigKRLS')
library(bigKRLS)
vignette("bigKRLS_basics")
set.seed(2017)
X <- matrix(runif(60), ncol=3)
y <- X %*% 3:1 + rnorm(20)
out <- bigKRLS(y, X)
summary(out)
The code above yields model estimates started with R2 = 0.663 (we've of course estimated lots more complicated models on other platforms).
Windows RStudio loads library(bigKRLS) without warning; bigKRLS() outputs that it's cleaned the data successfully. Among other things, that means y and X are now big.matrix objects. Then the first "real" step: bigKRLS() calls bGaussKernel(), which is where the session aborts after two minutes or so. But there doesn't seem to be anything wrong with bGaussKernel(). bGaussKernel() runs just fine if called from the command line in under a second. In fact, if you initialize each variable that bigKRLS() requires, you can run all of its code in Windows RStudio.
Currently, the package detects when Windows RStudio is being used and safely exits the function, directing users instead to RGui. Any suggestions as to a better a workaround would be greatly appreciated!
First, the problem on Windows is not related to the compiler. If you managed to install RTools correctly, then everything is going well for using RGUI. Instead, the problem that you are having seems to be with RStudio's use of Boost for their application that accidentally polluted calls to the boost namespace provided by the BH package in the rsession process. RStudio, more so #kevinushey, recently addressed this issue by creating a custom build of Boost for RStudio that lives within rstudio_boost. The details and solution of this error can be found in more depth at https://github.com/rstudio/rstudio/pull/1061.
Long story short, if this is indeed the case, simply check if the RStudio version is >=1.1.129 will suffice. To do so, you will first need to get an RStudio daily version. With this in hand, we can reference the solution that #DirkEddelbuettel derived for his fabulous anytime package that was running into this issue. Specifically, to overcome this, he has added a short isRStudio() function on package load and calls the function each time before handing data off into C++.
The isRStudio() function #DirkEddelbuettel uses is given as:
isRStudio <- if (Sys.getenv("RSTUDIO", unset="0") == "1" &&
exists("RStudio.Version") &&
## the following is evil but keeps R CMD check off our back
eval(parse(text=paste("RStudio.Version()$Version",
">=", "\"1.1.129\"")))) TRUE else FALSE
Note: The use of eval(parse(text=...)) is to avoid running into package check issues such as...
.onLoad: no visible global function definition for ‘RStudio.Version’
Undefined global functions or variables:
RStudio.Version
Debugger shows me dissassembler code, while i am trying to step over the instructions of my program.
Using lldb under QtCreator.
Interesting thing is: debugging works fine, if i use it without QtCreator (via terminal)
Small projects seems to debug normally... So I've try to add peaces of my project gradually to small one.
I've found a peace of code, that resulting to crash:
QVector<myClass>::contains();
But if i try to make an empty project only with this realisation, problem disappeared.
I've lost about a week, trying to solve it.
Any ideas, what can go wrong?
EDIT:
Well, QtCreator still using GDB instead of LLDB, that i refer it to...
Looks like bug
the problem is not to debug c, php, python, etc in emacs, but debug emacs itself.
i have confronted with a segmentation fault error when i try to enter gdb mode in emacs using
Mx gdb Enter
now i have build emacs with debug info, and have load it using "gdb emacs" command.
l command shows the source code of emacs,
now my problem is how to debug emacs? where i should set that breakpoint?
howto find the origin of segmentation fault using gdb?
the following is a screenshot about what i have did now, so any suggestions how i should debug emacs? and where to set break points?
http://i1271.photobucket.com/albums/jj624/bigmeowOoO/emacs_where-i-should-set-breakpoint-when-debug-emacs.jpg
howto find the origin of segmentation fault using gdb?
Don't set any breakpoints (yet). Simply use run command. That will start emacs running (under GDB control).
In that emacs, do M-x gdb. emacs will crash (if you are lucky), and you'll get (gdb) prompt right at the crash point.
From there, use gdb to examine the state of emacs at crash point. Figure out which variables have wrong values, etc. Then figure out where these variables are set, set the breakpoints there, and repeat (just as you would if you were debugging any other program -- there is nothing special about emacs being your buggy program).
P.S. Please don't post pictures where a simple text cut/paste will convey exactly the same information.
I am new to Ruby so have installed RadRails, Ruby 1.92 and ruby-debug-ide19. I have a very simple ruby program that prints hello world. But when I try and place a breakpoint in the code and run in debug mode all i get is the following line on the console:
Fast Debugger (ruby-debug-ide 0.4.9) listens on :51224
Why does it need to listen on a port anyway? And how can i get it to run my program until the breakpoint?
Personally, I don't bother with an IDE for debugging. I prefer to be closer to the metal... err... command-line, so I use ruby-debug19 from the command-line.
rdebug some_file_to_debug
For the basics use:
b to set your breakpoints
n to step over methods
s to step into methods
c to continue running after hitting a breakpoint
c n to run to a particular line then stop
p to display a value
h will display the built-in help
irb drops into IRB with the current variables pre-initialized so you can poke at things with a stick and see what they'll do.
More docs are at the Ruby-Debug site.
It uses the port to communicate between the IDE and the ruby-debug process, ruby-debug-ide is opening a port and waiting for the IDE to connect to it, but that happens pretty must instantly.
From what you've stated, debugging should already be working: You can right-click and select Toggle breakpoint, or double-click on the left-hand gutter of the editor. When your program hits any enabled breakpoint line the program should suspend and you can inspect variables, the stackframes, execute arbitrary code, step into or through your code, continue, etc.