Since some days I am having strange problems related to JetBrains Webstorm. I have set some breakpoints in index.html (some javascript functions defined in script tags), but when I debug an application, I see app stopping on different points, or pretending to stop on lines not existing in file index.html (line 272, in a file with 270 lines).
Who knows what is happening? invalidating cache and restarting don't have any effects. The only things to do is to remove all breakpoints and set them again: for the first time, it works as expected, but on next times it doesn't work at all.
It seems that this happens after I made a little mistake. When you rerun a app already running, usually Webstorm ask you if you want to stop currently running instance and starts new one; I was wrong, and I checked "Don't ask again" checkbox, so this popup doesn't show anymore. How can I restore original behaviour?
To restore original behavior (showing a dialog on restarting current debug session), remove <property name="restartRequiresConfirmation" value="false" /> key from .idea/workspace.xml.
the breakpoints issue is likely caused by having several embedded script tags in .html - see WEB-14466
Related
I've just updated a major C++ project from VS2010 to VS2019, and I'm having problems getting Edit and Continue to work like it used to, specifically in relation to the 'Require source files to exactly match the original version' setting (which I will refer to as the 'require match' setting, because it's shorter).
I'm used to running my program, making changes to the source code while it's running, then setting a breakpoint to catch the running application just before the changed code. When the breakpoint is hit, I could hit F5 to rebuild and continue.
In VS2019, it seems that Edit and Continue will not work without the 'require match' setting, but setting breakpoints in existing code cannot be done with 'require match' once any changes are made.
There's a couple of workarounds, but none are ideal. It's possible to turn on "require match" to build and run the program, then after some code changes are made, turn it off to set the breakpoint, then turn it back on again for the rebuild and continue. That's a huge pain. It's possible to use pause and continue to force a rebuild of any edits, but this only works if the code change is complete enough to build. If I want to break to inspect a variable, this doesn't work. Once or twice I did manage to set a breakpoint on changed code, and it automatically went to the stale code, which is acceptable, but I can't get this to happen now. Also, now I have breakpoints that are showing as valid on edited code that has been rebuilt and I know is running, but the breakpoints are not being hit.
Any solutions here, or does Edit and Continue simply not work as well as it used to?
Here's some pictures...
Firstly, while my program is running, I made some change to surfdraw_panels.cpp, then went to add a breakpoint. It shows the following message...
Then loads up a [stale] version of the code, with the breakpoint set in the stale code...
Other times, when I make a change, I get a different result, and it won't allow me to set a breakpoint at all... In VS2010, it was possible to turn off the 'require match' setting and still use 'Edit and continue', but VS2019 will not allow this, even though it is still the recommended 'solution' in the message!
Github project that shows the issue is below. It's a simple MFC app, dialog based, created by the new project wizard in VS2019. There is a single button on the dialog, and some simple code to do something in the button. To recreate the problem, start the app in the debugger, then make a change to OnBnClickedButton1(), and then try to set a breakpoint.
https://github.com/surfdabbler/MFCApplication1
Not quite understand your specific situation and operation, because there are not some pictures and code to explain the issue in detail.
But this function which I used could break into the changed code during debugging with require match option. You should move your cursor back to the changed code and then Debug the below code step by step. And when you move the cursor back to the changed code, vc++ project will rebuild the changed code automatically and you do not have to stop debugging and restart build.
Update 1
I also faced the same behavior in my side. And since we could not handle the issue here any more, I reported the issue on our DC Forum.
You can vote it and add any comments if I did not describe the issue in detail so that it will get more Microsoft's attention. And I hope the Team will give you a satisfactory reply.
Looks like a stupid question, but I just can't make the code execution stop at breakpoint
I tried to run the project by both pressing F9 and F11, but it still does not stop at the breakpoint. I use the local url http://127.0.0.1:8000/task_list/ which should call the createTask view. And it does actually call the view, and everything works perfect with the only exception that the debugger ignores all my breakpoints
Most major ide's have two different ways of running normally,
Debug - This is usually denoted by some sort of bug image (as shown in your screenshot) or separate symbol
Run - This is usually a "play" button
The debug mode is the one you want, this is the one that inserts debug symbols. The run doesn't set any of these up so you will find that your program may run slightly faster this way, which makes it more advantageous when modifying files that don't require you to restart the server.
So I keep getting this error when trying to compile C++ code using CodeBlocks.
cannot open output file [filename.exe] permission denied
It only started today, and it's sporadic and inconsistent. It usually goes away if I shut CodeBlocks down and restart the project, but not always. Sometimes it even goes away when I just press F9 (build & run) several times. I always check Task Manager, but there are never any .EXEs running with my file's name, or anything related to it.
I've also noticed that if this problem occurs and I then try to delete the .EXE manually or otherwise interact with it, Windows tells me I need administrator permission to do so (this is a private PC, and as far as I know I am an administrator on it).
The first time it occurred, the only thing I had added to the code beyond what was in the previous version was a debugging report sent to cout - hardly anything arcane. It sometimes occurs even when no code was changed from a previous version.
What could this be? It's not game-breaking, yet, but it's irritating and I'd rather it didn't get worse.
EDIT: This is old by now, but just in case anyone else is having similar problems, the workaround I currently use is just to consistently delete [filename.exe] before trying to run the code again. This avoids the problem, though it is annoying.
check that "filename.exe" is not running, I guess you are using Microsoft Windows, in that case you can use either Task Manager or Process Explorer : http://technet.microsoft.com/en-us/sysinternals/bb896653 to kill "filename.exe" before trying to generate it.
I have encountered the same problem you have. I found that it may have some relationship with the way you terminate your run result. When you run your code, whether it has a printout, the debugger will call the console which print a "Press any key to continue...". If you terminate the console by pressing key, it's ok; if you do it by click the close button, the problem comes as you described. When you terminate it in the latter way, you have to wait several minutes before you can rebuild your code.
I just had the same issue. And i experienced that it always happens when i run the programm and change some code without finishing the programm still running. After that the "cannot open ..." message appears.
However i got rid of it by clicking the "Terminate" button at the very top-right side of the console window (red button) and after that "remove all terminated launches" (two x'es right next to the terminate button).
This seems to close the running programm and everything works fine after :) hope this may help anyone
I was having the same problem too and it was driving me crazy:
Windows7 64 bit, MinGW, Eclipse, CDT
Permission denied errors, executable disappearing, ld.exe errors. It would work once, but never again.
Statements like: "cannot open output file ***.exe: Permission denied"
Check your ANTIVIRUS Software. Once I turned off my Antivirus software in workspace then cleaned the workspace and started the project over again I never had the problem again.
This error usually occurs when the IDE has a problem due to a crash or other failure and it still has a hold on the EXE, preventing the user (yourself) from overwriting / deleting the EXE during a rebuild.
Hello I realize this post is old, but here is my opinion anyway.
This error arises when you close the console output window using the close icon instead of pressing "any key to continue"
The problem is related to Sam´s response:
"have encountered the same problem you have. I found that it may have
some relationship with the way you terminate your run result. When you
run your code, whether it has a printout, the debugger will call the
console which print a "Press any key to continue...". If you terminate
the console by pressing key, it's ok; if you do it by click the close
button, the problem comes as you described. When you terminate it in
the latter way, you have to wait several minutes before you can
rebuild your code."
Avoid kill processes, and we have two choices, wait until the process release the .EXE file or this problem will be solved faster restarting the IDE.
You can use process explorer from sysinternals to find which process has a file open.
Try restarting your IDE. It worked for me.
Although I tried to end the process in the task manager, the process never got killed.
I re-installed C::B in drive D, whereas my program files folder is in drive C
I don't know the reason , but it works :)
well,once i had the same problem and after tracking down the process that was getting the file in use i discovered that it was the anti-virus (PANDA) ...i just unlocked the file and simply worked out ....well for my experience i used Unlock 1.9.2 ...try iy out ..
A major cause of this (which I had recently), is if you have this on for example a flash drive.
You can develop and do everything, but on most systems it stops you from running the .exe file from there, whether it be the debug or release version.
In my case - I found a process called
cb_console_runner
I stopped this process and things were ok again.
I had the same Problem. Just rename your .CPP file to other name and try it again.
It worked for me.
FOR LINUX OS...
go to file where u r created file.then usually
......project_name/bin/Debug/project_name.executable here for this executable file you wont be having execute permission then the execute permission.Either by right click if you are unable to change permission then use use open terminal(command promt) to change permission.
first go to that executable file using 'cd' command then use "chmod u+x" then permission is going to change.then go to c::b open and execute you will get output.
only thing for all file u need to do it.
The problem is that you don't have the administrator rights to access it as running or compilation of something is being done in the basic C drive. To eliminate this problem, run the devcpp.exe as an administrator. You could also change the permission from properties and allowing access read write modify etc for the system and by the system.
Make sure to run 7zip in 'Administrator mode' for extracting to Program Files.
Also, temporarily turning off virus protection worked for some people in the past.
I tried what #willll said, and it worked. I didint find exactly the .exe named after my project, but I did kill some weird looking tasks (after checking on the internet they were not critical), and it worked.
I have tried and get output after end task IDE from task manager. Later clean all temporary files from your drive. Start your IDE. Now your .exe working good.
Question has been asked before and I see bug report on ddd newsgroups but none of the suggested solutions work for me.
It comes up but when you try doing anything like opening a file it hangs with the message "waiting until GDB gets ready."
A crucial fact, reported by others too, is that it works fine for some users and not others. I've compared the environments and can't find any significant differences. Any suggestions will be most appreciated.
Encountered this problem too. The easy solution as posted above is to delete the init file in the ~/.ddd/ directory.
But that means all your customizations will be gone. So I started hunting for the real cause. I observed that the problem only occurs after I have used the "GDB Settings" dialog. Once you opened this dialog the init file mentioned above will grow because a lot of gdb settings will be stored there.
After shrinking those additional lines step by step I found the "offending line".
The problem is caused by the setting for extended-prompt. After opening the GDB settings dialog this line will read like
set extended-prompt not set\n\
This "not set" is what gdb will report on "show extended-prompt". Unfortunatley "set extended-prompt
is sort of buggy in gdb, so if I enter "set extended-prompt not set" in a gdb running from a shell without ddd involved gdb will lockup as well.
It looks like the only safe way of setting the extend-prompt is when it contains the string "(gdb)". So I modified the offending line in the init file and now it reads like this:
set extended-prompt (gdb) \n\
With this setting I do not encounter the problem any longer. Hope that helps in your case too.
Removing ~/.ddd seams to solve the problem.
Doing a Ctrl+D, then choosing "Restart DDD" seems to work for me.
The problem arises when opening the GDB Settings... window, even without touching any setting.
Because removing the entire ~/.ddd/ configuration directory every time is not a way to go if you have customized your DDD environment, I have found a solution to fix the ~/.ddd/init file that could help you too without removing the entire configuration.
Close DDD and open with your text editor the file
~/.ddd/init
Search the line
set extended-prompt not set\n\
and remove it or replace it with
set extended-prompt \n\
Save and run DDD. It will start as it should.
Because this task can be tedious to repeat every time, especially if you change gdb settings quite often like me, I suggest you to create an alias in your shell environment like this.
alias fix-ddd="sed '/not set/d' -i $HOME/.ddd/init"
This last approach has the advantage that it will work for any bugged setting in the init file, without your specific intervention.
If you don't want to use the cli to fix the init file another approach is to edit the init file as suggested previously and if it happens to you to open for any reason the GDB Settings... panel then remember to disable in the Edit menu the option Save Options and leave it disabled until the next DDD restart.
For the sake of completeness (as stated by #hmogal) hitting
CTRL+d
during the GDB hanging kills GDB and restarts it allowing use DDD. Unfortunately this approach is not a good solution because it erases the entire GDB configuration inside the init file, even settings specifically tuned by you. So pay attention.
Everything tested with DDD 3.2.12.
I think removing the init file inside .ddd will also solve this issue. No need to remove the entire .ddd folder. I tried it and it worked !
Also, if you extensively modify the ddd default options such as Buttons and Graph Displays, you can move your init file to outside this folder and then copy some of the options back to the init file created by ddd by default.
Note: When you restart ddd after removing init file, it will create the default init file.
If the issue persists, the following workaround may help:
open ddd as you would normally (eg. ddd --debugger bashdb script.sh)
type exit in the lower pane of ddd
This seems to kill one instance of bashdb, and then another instance of bashdb seems to run. This 2nd instance of bashdb seems to work fine, with the bash-script source finally appearing in the top-pane and allowing you to step-through and debug.
Using Ctrl+D pops up a dialog box asking to restart GDB which fixes the issue. In my case deleting ~/.ddd or init file in this particular folder didn't help.
Decipher's suggestion of simply deleting the init file worked for me as well.
And for those that don't know, ~/.ddd is the .ddd folder in your home directory.
I'm using xcode in C++. I'm trying to debug my project, but at random intervals, it seems to ignore my breakpoints. There are three things that it does:
1) Sometimes, when I run, it automatically switches to "de-activate break points" mode. (the relevant button goes light and says "Activate")
2) Sometimes when I run, ALL of my breakpoints go "can't find" mode, with the yellow insides. I need to click twice on them to get them back dark blue (once to light blue = inactive, once to dark blue = active)
3) Sometimes, when I run, my breakpoint is dark blue, the button says "deactivate" and it still just ignores my breakpoint, running straight past it.
This makes it very difficult to debug my program...
I should add that I'm using XCode 3.1 beta on OSX 10.5.6, in case that matters.
thanks.
Try unchecking the Load symbols lazy in the Debugging panel in Preferences
alt text http://img.skitch.com/20090209-gj947qk7dxdyms1wij4q5em2f2.jpg
Had the same problem but only restarting the iPhone Simulator seemed to fix it.
I faced the same issue right now.
I tried all the options : enabling the GCC, active, base targets and restarting and closing xcode, nothing solved.
I finally restarted the simulator and things have started working.
I have more or less the same set of issues, and this suggestion of loading symbols lazily unfortunately does not resolve it for me. Moreover, I am not developing for the iphone, just a regular application.
To be specific, sometimes I can't disable or enable breakpoints on the fly - sometimes my code doesn't stop in breakpoints which I later prove are being executed (with print statements) and nothing I can do will make it stop there - I see that very annoying debug symbol with an orange center, even though I only have one project active.
Quitting and restarting XCode occasionally has an effect - and annoyingly, there have been a very small number of cases where quitting and restarting or rebuilding from clean fixed hard-to-diagnose compilation/linking errors. Unfortunately, I just tried all of these with no effect.
(Unrelated, my keyboard shortcuts are also unreliable. My shortcut of F2 for continue worked for weeks for me, stopped working for a long time, was working this morning and now doesn't work at exactly the same breakpoint it worked before - yet my F1, step over, key has been completely reliable...)
I'm a little disappointed to have to do so much debugging with print statements!