I'm using Qt Creator on Ubuntu to develop C. Whenever I run with the debugger, I get the message warning: GDB: Failed to set controlling terminal: Invalid argument. This happens even with a hello world program. How can I solve this?
This is a bug in Qt Creator, which is not invoking GDB correctly (either inside a pseudoterminal, or with command line arguments that tell it not to expect to be run inside a pseudoterminal). It is also a bug in GDB, which could figure out for itself that it wasn't being run inside a pseudoterminal and behave accordingly. I suspect the GDB maintainers will take the position that this is Qt Creator's fault, and vice versa, alas.
There is a claimed workaround here: http://www.qtforum.org/article/31905/debugging-qt-application-on-linux.html but it sounds kinda dodgy to me.
Whether this warning is a bug or not, it is informative as a clue that you have the option to tell QtCreator to cause your program to run in a terminal which may be useful for debug output. See Setup GDB with QtCreator to enable this option.
If you don't want a terminal open, then just ignore the warning.
Related
When I install a fresh Eclipse, I can open the program, but when I attempt to create a new blank cpp file or open a file, the program stalls, I get a popup as seen below, and the terminal from which I launched the application looks like the 2nd attached pic. Can anyone help me with this? I'm not sure how to interpret these errors.
Popup:
Terminal:
I solved this myself. In case this comes in useful to anyone else, the answer was found
here
Essentially, before launching eclipse I type:
export GTK_IM_MODULE=ibus
The default value seems to be xim, and apparently is responsible for a number of issues. A small script could be made to automatically do this assignment, and then call eclipse.
This solved my issue.
I've downloaded clion and installed it on linux ubuntu to be able to use swift on linux. It works fine except for the fact that whenever I hit either the "backspace" or "delete" button, it just closes. No error message, nothing.
-- Edit --
I actually just tested some more and noticed that it closes on whatever input you give it... (as in random letters)
I've checked the keyboard shortcuts in the settings, but couldn't find anything that could cause this. Building and running the projects works, so I'm guessing it has nothing to do with a faulty installation...
What could cause this?
When I run C-c C-l haskell-mode reports "Can't find the prompt".
My questions are as follows:
how would I go about debugging this problem? "Can't find the prompt" in itself is probably too little information, so how would I go about finding what the underlying problem is?
what kinds of issues are likely to be responsible for this error?
Check the output of your *Messages* buffer, clues are usually hidden there, though since sometimes they arise when you first load up Emacs, they can be difficult to find. You might be getting the error because your haskell-mode process has not even started, as was the case for this fellow.
Just for an additional thing to check, on MacOs I was stymied by this error until I realized that I hadn't completely set up my xCode, which I found when I tried to run ghci at the terminal and got an xcode licensing prompt.
Can anyone tell me which command is used to display the source code when debugging through GDB.
Would be of great help.
You can enter or leave the TUI mode with code window using Ctrl+x A key binding. Or use layout src command to enter TUI mode. See other TUI key bindings and commands.
Start gdb using gdb -tui. tui stands for Text User Interface.
Or, use 'ddd' -- a graphical front end for gdb.
The list command will show the code around the line where the program is currently stopped. If you type list again you'll see more.
This is what the commands in the source category of the manual are for. More specifically, the sub-category list mentions the command list.
Note that gdb is not typically using "windows", it's a console application.
By using layout next we can see the source code on different window. If the program didn't start running we will see empty screen for the beginning, when it starts the program will appear on different window.
The Perl debugger always says: "Editor support available". I believe every one can see this, but how can I use it?
my-computer$ perl -de2
Loading DB routines from perl5db.pl version 1.33
Editor support available.
Enter h or `h h' for help, or `man perldebug' for more help.
main::(-e:1): 2
DB<1>
By the way, I got the above prompt on a Linux/Ubuntu 11.04 (Natty Narwhal) machine.
The message is a little confusing. It's telling you it can support running inside an editor, not that there is a special Perl debugger editor.
The Perl debugger can detect if it's talking to a terminal or if it's running inside an editor. This controls a number of things, the biggest is whether the debugger prints anything or leaves it up to the editor to handle the display. If you're really curious, look through the debugger code for $slave_editor.
Why does it feel the need to inform the user of this? I did a little digging and the debugger used to only support Emacs debugging. It's a bit more useful to inform the user "Emacs support available" than that some editor somewhere will work with the debugger. The Emacs message came in with the first version of the debugger sprung fully formed from the head of Ilya.
The Perl debugger is also really three entities. The perl5db.pl script, the DB API, and the debugging hooks in the language itself which those two use. An editor may use perl5db.pl, or it may talk directly using DB.
There are a few editors which can hook into the Perl debugger. One is Emacs which you can start by opening a Perl program in Emacs and using M-x perldb. Komodo and Padre also have debugger support.