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.
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.
I know the answer to this, I'm putting it up here for others to see it
If you use eclipse CDT, you probably understand that eclipse isn't a debugger, it's just an application front-end, specifically to GDB. So when debugging C++ programs, you're actually just using GDB in a more comfortable manner. If you ever have to debug a multithreaded program in eclipse CDT, you'll realize that things quickly get hectic because when you hit a breakpoint, all threads stop, and when one tries to execute a single line in a specific thread, it also runs the other threads. In order for it to work properly, the threads have to be able to be run arbitrarily and exlusively-so that when the programmer executes a single line, it only executes the specific thread.
So, by default, gdb's settings by default leave the "scheduler-locking" turned off. If you debug multithreaded applications you'll understand that this must be on in GDB in order for the desired behavior to be achieved. How does one run this command:
set scheduler-locking on
in GDB within eclipse CDT?
At least one way to do it that certainly solves the problem is knowing how to navigate the immense set of features that eclipse offers. Typically, when a program starts, eclipse CDT switches the console window (if you have it open, typically it's on the bottom) to show the input/output of the program.
But you can change this if you didn't know-see this image. That button on the second to last right-the blue one that looks like a monitor-you can select the GDB input console. It was discussed also in this thread.
From there merely type the command.
SOLVED, BUT NEED A BETTER SOLUTION
But now that this has been solved, to solve it in a better way as a matter of convience; having to type set scheduler-locking on every time a program starts is silly. But the problem with loading a gdbinit file is that the gdbinit file gets sourced before eclipse has set the program for gdb to solve. This is a problem, as it causes the debugger view to hang within eclipse, as gdb complains. To understand what is happening, try and fire up gdb, then give the command without loading a binary to execute. It fails-so how does one set this as an option that is sticky?
Maybe if you add the following gdb script which could set the variable when the program stops and turns it off if you continue:
define hook-step
set scheduler-locking on
end
define hookpost-step
set scheduler-locking off
end
define hook-run
set scheduler-locking off
end
define hook-continue
set scheduler-locking off
end
My answer is derived from the one by #user1448557 . Unfortunately, I don't currently have enough reputation to comment on it (or to upvote it by the way). The strategy seems great, but the answer might be a bit outdated because it doesn't involve "set scheduler-locking step". I have put the following in my gdb initialization file (within my Eclipse project) and it does what I want.
#inspired from [link to this thread][1]
define hookpost-run
set scheduler-locking step
end
With regards to the comment by #rbaleksandar, Eclipse CDT launch configurations allow one to specify a "GDB Command File" and the default is usually .gdbinit
Problem A:
I start gdb in command line with "gdb test"
I press ctrl-x,ctrl-a before I do anything else
Then I set break point using "b main"
Then I start running the program using "r"
Till this point, if I press the Up arrow key the src window will not scroll. Instead, something will appear in my command window - "^[0A". If I try to refresh the screen with ctrl-l, "^L" is what appears in the command window.
I don't think this is supposed to happen. Under this situation I can't even quit tui mode with c-x,c-a ("^X^A" will appear instead). Am I doing something wrong? I realize this problem occurs so long as I use the "run" command inside the TUI interface. I can, however, use the run command in TUI if I start gdb with "gdb -tui"
Problem B
I can't see the output of my program in TUI mode. GDB's own output can be seen, but not that of the program being debugged. This occurs both when I enter TUI using ctrl-x,ctrl-a and when using -tui command-line option.
Is there any way to fix this?
I've read some TUI articles on the net and some people seem to use TUI "exclusively". I suppose TUI can work properly, it's just there's a set of rules that must be carefully followed?
EDIT: I use gnome-terminal in ubuntu 11.04
Run gdb with -tui option instead (https://bbs.archlinux.org/viewtopic.php?id=112660)
~/.inputrc was the culprit in GDB 7.7 because of:
set editing-mode vi
set keymap vi
If I remove those lines it works.
This seems to be mentioned at in the following bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=15163
I have requested a workaround at https://sourceware.org/ml/gdb/2015-06/msg00009.html and Andrew Burgess replied that he had just submitted a well received patch to add:
tui enable
tui disable
so in future versions we should have commands as an alternative to the shortcuts.
But then I saw the light and moved from TUI to GDB Dashboard: https://github.com/cyrus-and/gdb-dashboard which is simply more powerful and less buggy. See also: How to highlight and color gdb output during interactive debugging?
Change your terminal to get rid of your first problem. I used to use gnome-terminal my self, but then changed to terminator. Some terminals don't support keys like Alt sometimes (used to experience this in vim with some Alt+something maps)
You can change forcus to another window by 'focus winName', in your case, use 'focus src'
got this from here
Not sure about your 2nd problem. Good luck!
I think you are looking for, "focus next." it switches you among (there can be more than two) the windows. I'm sure there is a short-cut for this too. Please note, this is almost the same answer as user1888039, so if you agree you should up-vote that answer.
Problem A:
Use Ctrl+X then press a to enter or exit TUI mode.
Or as you mentioned run gdb -tui
Problem B:
Note that your program print could be ran over by the (gdb) prompt. In other words, it is possible that your program prints but the " (gdb)" is printed over it after.
To easily check if this is indeed the case, try to print either a line longer than 6 characters or multiple lines each time.
You should see part of your print.
I'm having problems getting gdb to pause execution flow under NetBeans. The pause button doesn't appear to work at all. From this answer, I suspect it may be a problem with what text gdb is actually receiving as input (I'm under Windows/Mingw32 using IIRC msys bash). But this is just a guess.
I don't know where to view what is happening with gdb (input or output). I see a few mentions of it in the debugger console but not sure if that counts for anything. I'd post that log here but it is rather large.
This is apparently a general problem with Windows/Netbeans, for which detail can be found on one of the NetBeans site pages (can't remember which).
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.