When switching the TUI mode on and off (with Ctrl+x, a), gdb often gets stuck using only half the screen (so the cmd and src windows take only 1/4 of the screen each) and winheight cmd + 5 won't work.
How can I prevent or fix this?
This is apparently a problem related to readline.
Someone apparently already looked into it: http://patchwork.sourceware.org/patch/6398/ so hopefully it should be fixed in newer versions of gdb.
In the meantime, the following kludge can be used to fix the problem when it happens:
Toggle the TUI mode until you get the problem
Open another terminal on the computer where gdb is running and send SIGWINCH to the gdb process with a command like pkill -SIGWINCH gdb
Toggle the TUI mode a couple of times and gdb should pick up on the "new" height.
I had similar issue when I was working on Windows, connecting through Putty to my server where gdb was running.
I found out that gdb took from Putty information about terminal resolution (or putty delivered it to gdb?). Unfortunately, when Putty window was maximised, the information send/received described normal (restored) window size.
To solve it I just restored putty window to normal size, manually resized it to look as maximised and maximised once again. After switching TUI off and on I could work with whole the screen.
Related
Im trying very hard to like virtualbox, but so far I find it so much worse than vmplayer in so many ways. If it wouldnt take me hours to install everything back into vmplayer i would have moved back days ago
When I open my ubuntu vm my host OS's (windows 10) toolbar is still visible at the bottom of the screen, cutting off the actual virtualbox toolbar
Please help me
(edit) It is in fullscreen mode already, it just still shows the toolbar/taskbar from the host OS
Open Task Manager of Windows 10, Select "Windows Explorer" and Restart.
Reference Link
I had this same issue. The Windows 10 taskbar was still showing when I had VirtualBox in fullscreen mode, and what caused it for me was I had a program called Rufus (for creating bootable USBs) open and it was keeping the taskbar from hiding. Once I closed Rufus, everything worked as it should. So, maybe you had a program keeping focus on the taskbar, something that needed attention, and wouldn't let the taskbar hide.
I ran into the problem once. Not sure what had caused the that but I managed to find a solution by enabling "task bar" hiding option in host windows 10 machine.
Right Click on Task Bar -> Task Bar Setting -> Enable Task Bar hiding Option.
You are able to switch to fullscreen mode on the VM, this should hide the Host OS.
This image shows you where you can find the option:
If this is not what you are looking for, please elaborate on your problem, maybe add a screenshot showing the problem you are having.
I just experienced this exact problem, namely Windows 10 host taskbar would not go away despite the guest being in full screen. Even though this question is old, since this question got the top google page rank, I thought I would share how I fixed it.
I fixed it by shutting down Virtualbox and then rebooting the Windows 10 host. It is possible as others have pointed out that some app was keeping the taskbar active, but I couldn't find any such app. If it was some rogue app that was just running as a process (with no taskbar presence), the reboot nuked it from orbit and fixed the problem.
After installation virtualbox tools You can press
host + F (in my case Ctrl + F)
buttons to run fullscreen in virtualbox.
This used to work really well. I loved it. I showed everyone how cool it was. Now it's broke.
M-X gdb,
gdb -i=mi MYPROGRAMNAME,
set args,
run,
screen splits to show output,
C-X o to output screen,
C-X b to get to gdb commandline
BOOM, error message
Cannot switch buffers in a dedicated window.
I don't need the program output at this point and rarely do. I need to control gdb and see the source code but now I cannot use the program output screen to control gdb because it's a "dedicated window?". I have to split the program output screen into two tiny windows. Very sad. I need a drink.
Use M-x gud-gdb instead of M-x gdb. But it has drawbacks, e.g. you can't set breakpoints by clicking in the fringe. On the plus side, you can have several debugging sessions running in parallel.
I am trying to write up a C++ program for a class using XCode. One of the things I wish to do, is to simply clear the screen. I've looked into how to do this, however the catch is that the code needs to run on both a Windows and Macintosh computer. I've looked at some other similar questions, but none of the answers help me. I know there is no "screen" but I want the system to clear the output window. I know that the command system("clear"); does what I want it to, but when XCode tests the program, instead of clearing the screen it prints TERM Variable not set
I've tried opening up the terminal and typing clear and it does in fact respond the way I want it to, so why doesn't the 'terminal' inside of XCode do the same? I just want to get the output window in XCode to respond to clear the same way that the terminal already does.
Here is something I have already tried;
I went to the terminal and ran echo $TERM, to which the terminal responded xterm-256color. I then went over to XCode and opened the "Scheme" settings, and found an Environment Variables setting under "Arguments". I added a variable (to the blank list) called TERM and gave it value xterm-256color. Upon running the program again, the output displays ¿[H¿[2J in the output window, positioned where the TERM Variable not set used to be printed.
Last thing, as a reminder, I cannot change the source code from the way it is now, or it could cause errors when the program is run on a Windows machine.
It does not work because you are "lying": The terminal in Xcode is not a xterm-256color, but it is dumb terminal. More precise, the display represents a NSTextStorage that collects stdout and/or (depending on target switch) stderr.
A dumb terminal is not able to clean the display. If you want to change this, you can write a plug-in similar to Xcode-Colors what adds the ability to understand ansi color codes.
However, if your requirement that the code simply run at Windows and OSX, you may stick with your solution system("clear"), since it works prefectly in the "normal" OSX terminal.
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).