I am developing a package in RStudio and would like to use breakpoints to debug my functions. However, I keep running into the same problem: I set a breakpoint, RStudio warns me that the package has to be built and reloaded to activate the breakpoint (even if I just built and reloaded the package), and then when I build and reload the package the breakpoint disappears. Is there something I am not understanding?
move your .R file to the directory that .RData exist and then
setwd("directory of .RData file").
this solution worked for me!
It appears that this is a bug that was solved by closed and re-launching RStudio. I discovered that I was also having a problem with my saved datasets (in data/) not loading. So, I believe something was wrong with the package build and reload in RStudio that was solved by restarting the software, and this was what caused the strange breakpoint behavior.
I met same problem, and restarting RStudio didn't solve it for me.
One workround is to put browse() before the code that have error as a breakpoint, it will stop there and you have an interactive session to check the problem.
This is a very thorough article explaining all debugging options available in RStudio. I found it really helpful.
In my case, it was due to the fact that I had placed copies of the .R file in the R folder of the package. I made those files to keep the minor changes for a while.
It seems that the breakpoints will be overwritten by the other functions, that has the same name as the function I intended to set the breakpoints, defined in other .R files.
Related
For the last 2-3 weeks, my VS Code terminal has been blank. Not sure when it exactly started or what might have changed to cause this.
I usually use GIT Bash as my default terminal in VS Code, but this happens even if i switch to CMD or Powershell.
I have already uninstalled/reinstalled VS Code (did not solve the issue).
I have also seen this issue online, but no real solution seems to be out there.
Is there some VS Code setting i can fiddle with to try and fix it?
Also, When i have VS Code open to a project, I do get a file put into my project folder named bash.exe.stackdump which some very odd numerical info dump. Nothing easy to decode.
Here's how I have solved this issue.
I unchecked the compatibility mode in VS Code properties where it says Run this program in compatibility mode for:
Recently, whenever I change something in my code, rebuild, and attempt to debug, I get the error "This breakpoint will not currently be hit, No symbols have been loaded for this document."
But then as soon as I restart my computer, everything is fine and I can debug properly. Why is this happening? It's really frustrating having to restart my desktop every time I try to debug my code. I've looked all over stack overflow and MSDN and can't find any solution to my particular problem. Any help is appreciated
"This breakpoint will not currently be hit, No symbols have been loaded
for this document."
(As for this error message, it's common error which has different causes. I can't give the most direct correct answer for this issue, I can only give you some tips for trouble-shooting. In order to avoid losing contact in the round-trip comments, I post those content as answer instead of comments.)
Since VS2015 have been released for long time, I would think this issue is a particular one, not found similar issues online.
First of all, please create a new simple project to check if this issue occurs in new project when debugging.
If it persists in new project, I think this issue has something to do outside environment like VS settings, VS config files or Debug options.
You can try:
1.Go Tools=>Import and Export Settings=>Reset all settings =>No,just reset settings=>Finish
2.Repair VS IDE since it seems to work well in the past, and just got the issue recently, so maybe something is broken for your IDE(In Control Panel find VS2015, right-click=>change=>repair). Also, make sure you have the latest VS2015 Update3 instead of earlier versions.
And if it works well in new project, then maybe the issue is about the whole project or solution itself. You can try:
1.Navigate to solution folder, close all vs instance, delete the .vs, bin and obj folders and restart VS to check if it helps.
2.Make sure you've loaded the required symbols, check the content in your Modules window during debugging, there's possibility you don't load necessary symbols successfully.
3.Check the output folder after your rebuild, check in folder like bin\debug folder if you have both the .exe and .pdb files. And make sure the .exe and .pdb files are up-to-date after your rebuild by checking their Date Modified.
Hope it helps and more info about the project type, dependencies would be better:)
As you can notice
Symbols are been correctly loaded.
I just created a view GetCompanies.cshtml using the AddView shortlink
But, no matter what I do, I can't debug in the View.
What I did so far:
Close and Open Solution
Close and open Visual Studio
Shutdown all ASP.NET Development Server's
Deleted all Symbol Libraries .pdb
Clean Solution
Re-Build Solution
did not (yet) shutdown Windows 7 x64 :-/
Sometimes if you have a hard stop, Visual Studio temp cache will be screwed.
Clear the cache by deleting these folders:
C:\Windows\Microsoft.NET\Framework\<.net version>\Temporary ASP.NET Files\(ApplicationName)
C:\Windows\Microsoft.NET\Framework64\<.net version>\Temporary ASP.NET Files\(ApplicationName)
I am finding the same behavior from time to time when debugging silverlight. My solution is to clean the browser's cache (on latest IE click on the wheel button, Developer tools), as it sometimes will cache the binary files and not load the new ones.
Perhaps is could be the same with your views?
Been messing with this problem for a couple hours trying everything above. I finally changed my Target Framework to .NET Framework4.5 and it all started magically working.
This is always weird. I just had this problem and solved it with a full rebuild of the entire solution.
There was also another strange symptom, though: a new unit test that I had written using NUnit, mocking with NSubstitute, wouldn't pass because NSubstitute wasn't returning what I wanted it to return. I lost a few minutes trying to figure out if I did something wrong programming NSubstitute, then when I tried to attach the debugger to the NUnit GUI I saw that warning.
That's when I decided to do a full rebuild of the solution, and that worked for me.
So I guess the lesson to be learned is "before smashing your head against the wall, try a full rebuild".
For me, I somehow switched my target build to Release instead of Debug
Remember that views are actually compiled when you request the page (by default).
This means when you set a breakpoint in a view:
It shows the "No Symbols" error. This just means the view isn't
compiled yet.
It shows the breakpoint fine. This just means
that it found SOME compiled version of the page. Like the LAST working version...
So basically its not meaningful information to look at what it says when you mouseover the breakpoint in a view (at least in this regard)
If you are trying to debug this page, then you have a problem. Look at what the debugger is outputting to your BROWSER instead and fix that first. I think we'll be surprised about how many people are going to facepalm at this.
I had this problem with SL5 project (VS2012). And to fix this, I was needed to set "Silverlight" option enabled in %MyProjectName%.Web project properties, under Web tab.
In my case, the .PDB file was hosed (from which the symbols are loaded) in VS 2012, so performing a Clean and Build reconstructed the .PDB file and everything started workign again.
I was attempting to debug a deployed WCF windows services (compiled in Release mode) and had the exact same issue. Give this a shot...
Save All. You may even want to try to clean the solution
Rebuild all and install or deploy
BEFORE starting the service (or exe) I copied the .pdb files over to the install folder
Start the service (or exe) and attach the debugger to the process
Worked like a charm (finally) for me.
delete bin and obj directories
run solution again.
Note: Unless that cshtml loads at runtime the symbols are not loaded. On page load that breakpoint will be hit. So wait till control goes to that page
I set a breakpoint in my code in Visual-C++, but when I run, I see the error mentioned in the title.
I know this question has been asked before on Stack Overflow (Breakpoints cannot be set and have been disabled), but none of the answers there fully explained the problem I'm seeing. The closest I can see is something about the linker, but I don't understand that - so if someone could explain in more detail that would be great.
In my case, I have 2 projects in Visual C++ - the production dsw, and the test code dsw. I have loaded and rebuilt both dsws in debug mode. I want a breakpoint in the production code, which is run via the test scripts. My issue is I get the error message when I run the test code, because the break point is in the production code, which isn't loaded up when the test starts.
Near the beginning of the test script there is a mytest_initialize() command. I imagine this goes off and loads up the production dll. Once this line has executed, I can put the breakpoint in my production code and run until I hit it. But it's quite annoying to have to run to this line, set the breakpoint and continue every time I want to run the test.
So I think the problem is Visual C++ doesn't realise the two projects are related. Is this a linker issue? What does the linker do and what settings should I change to make this work?
Thanks in advance. Apologies if instead I should be appending this question to the existing one, this is my first post so not quite sure how this should work.
[Update 1] I think Chris O has identified the problem. I'll add a further update if I'm able to work out how to use the project settings to make this work.
It sounds like you are using VC6, since you mention dsw files. I think that is as good as it gets in VC6, you have to manually add the breakpoint after your module is loaded from LoadLibrary. Actually, there might be a project debug setting, so you can specify which DLLs to load when debugging your project, that will keep your breakpoints enabled when hitting F5.
You can also try attaching the debugger after you know the mytest_initialize() has been called, that might keep your breakpoints enabled.
I had this issue sometimes, but always pass this with some code replacement actions.
Here is some guy post, how he had fixed it.
Hope it helps.
In my case i solved this by setting the DLL project containing the breakpoint as Active Project and changed Debug settings for this project (right-click project>>settings>>Debug tab) to point to the project that actually runs and accesses the DLL. "Executable for debug session:" and "Working directory:" should be set to the executable that you actually want to run and its corresponding directory.
Hope this is of any help.
right-click project>>settings>>Link tab
check on Generate debug info
check on Link incrementally
Using Visual Studio 2010 beta, when I run my application within the IDE for debugging, it works perfectly the first time. However, after closing the debug session, either by closing the application or clicking the stop debugging button, all subsequent attempts to debug the application fail with:
Error 1 Unable to copy file "obj\Debug\Application.dll"
to
"bin\Debug\Application.dll".
The process cannot access the file
'bin\Debug\Application.dll'
because it is being used by another
process.
Handle.exe from SysInternals does show handles open, but even if I close the handles, the error doesn't go away. Any attempts to delete the file manually result in an "Access Denied" error message.
To fix this, I have to completely restart Visual Studio, afterwhich the Debug session will work once and stop again.
I'm not entirely sure when this started happening, but I'm pretty sure it's fairly recently.
UPDATE: After I force close the handles on Application.dll, I get the following error from VS:
Error 1 Unable to copy file
"obj\Debug\Application.dll"
to
"bin\Debug\Application.dll".
The requested operation cannot be
performed on a file with a user-mapped
section open.
What the heck is a "user-mapped section"??
UPDATE 2: It appears that this problem occurs when I have a Form open in Design view when trying to debug. I'm going to do some more troubleshooting and then post my results.
UPDATE 3: I think I've narrowed it down to a form using a UserControl.
To be honest with you, it sounds like a bug in VS2010. For some reason it isn't closing the open handles when the debugger stops. Killing the VS process automatically closes those handles, allowing you to access the file again. As a work around, you might look at unlocker it's free and works exceptionally well. I know that's not a great answer, but it should be faster than restarting VS. You might to consider sending a bug report too...
Unlocker doesn't work on 64-bit OS, LockHunter does though.
Here is how I solved this problem
*I open the project Properties,
*select the build tab,
*Clear the output path,
*and buid(this will create the dll in the root folder)
*come back to the output path and select browse(browse to the bin directory to either debug/release)and voila!
As per Error: Cannot access file bin/Debug/… because it is being used by another process answer by TarmoPikaro, sometimes Visual Studio creates multiple msbuild.exe ghost processes, which persist after build. These ghost processes seem to be causing file locks.
Solution 1 - Kill ghost MSBuild.exe's
Killing msbuild.exe's is a one time solution, it needs to be done per build basis.
You can kill the processes as follows mrtumnus:
taskkill /f /im MSBuild.exe
Solution 2 - Disable parallel builds in Visual Studio
You can disable parallel build once and for all:
Tools > Options > Projects and Solutions > Build and Run > "maximum numbers of parallel project builds" - by default it has value of 8, switch it to 1.
Of course builds are bit slower now, but mileage may vary depending on your use case.
This is related to
Error: Cannot access file bin/Debug/... because it is being used by another process
I've seen the Windows Indexing Service cause this. Disabling it helped. Virus scanners can also be at fault. Mutliple Application.Close() calls can supposedly cause this, too.
Of course, since it always works the first time, I suppose these are unlikely.
Had the same problem. The following things helped
Closing all design files while debugging
using unlocker
Also my application opens a port. While debugging an exception was thrown and program quit. While ending the program I closed the port. That helped too.
But definitely, bug with VS2010.
I encountered the same problem and in my case I had the file in question open in Visual Studio. Closing all files helped.
I faced the same error and I was stuck in it for many days. Finally resolved the issue.
I was working on a project that had many class libraries added in it. I added the reference of these libraries to my main project and mistakenly added reference to same project to itself. So when I removed self reference, it worked.
I had this issue myself. I had the project properties window open and that apparently creates a file lock. Even after I closed the window the file lock remained and I had to restart VS.
P.S. I'm using VS 2019. Just posting this for anyone having the issue I had and coming to this post.
If you get this error on VS Code;
Click on terminal screen and use "Ctrl + C" for stop running.