I'm trying to debug my ncurses application, using gdb. I use tty command to redirect program's I/O to another terminal. Output works like a charm, but I'm having problems with input. I'm using getch() function to retrieve symbols in my app. So, for instance, if I do in my gdb session:
tty /dev/pts/5
I get my output in another tab of my terminal window (gnome-terminal). My gdb sessions is getting stuck, waiting for input, but when I press any key within my /dev/pts/5 I get it printed out, but the app itself does not except it as an input symbol. When running without gdb everything works fine, I'm also using noecho(), so symbols should not be displayed.
So, what's the problem? Is it possible to somehow handle input from redirected terminal?
You can attach to your process to debug from a different terminal instead of trying to run the application from within gdb.
Run your process as normal. When it is blocked for user input, find its process ID, and then attach to it with gdb from a different window:
gdb -p <PID>
Your problem is due to the program still expecting its interactive input to be coming from your gdb session.
Maybe it's a bit late to answer, but hope this helps:
It took some time to figure out how to debug ncurses applications,
finally i made a very comfy way with the help of gdbserver and tmux.
This way I/O of gdb and the application are completely separated:
debug.sh (the script that starts debugging):
#!/bin/bash
tmux splitw -h -p 50 "gdbserver :12345 ./yourapplication"
tmux selectp -t 0
gdb -x debug.gdb
debug.gdb (one-liner gdb scriptfile for comfort):
target remote localhost:12345
So this way, application starts up on right side, gdb on left waiting to hit continue or any other usual gdb stuff :)
Once you exit, tmux automatically closes the gdbserver (therefore right panel as well) and that's all :)
Related
I'm trying to debug a simple program of several line with gdb from the command line.
The problem is that whenever I run the program it runs the program and then automatically assume that I wanted to quit and quit gdb for me.
I'm using gcc compiler and I've updated the version (which solved another problem that I had).
to clarify the problem is that it is not me who entered the quit command after the run command, gdb generates it automatically without asking me and then assumes yes.
I fixed this problem by running gdb in a cygwin window rather than a Windows command window. I get the cygwin window by running (i.e., double-clicking on) mintty.exe, which on my machine is at
C:\cygwin64\bin\mintty.exe
I'm trying to debug for the first time a gtk code and actually, I want to debug a callback function for key-press-event so I set a breakpoint with gdb and when it hits the breakpoint, the whole desktop evirement is freezing (I'm running under gnome-shell) it seems that the graphic envirement is waiting for the event to finish.
I got some idea that didn't worked :
The first attempts was to assign some gdb commands to the breakpoint :
(gdb) break on_key_press_callback
(gdb) commands
> back trace
> next
> next
> next
> continue
> end
but I don't know why, only the back trace command is executed, and then freeze.
The second attempt was to debug remotely using gdbserver and gdb on tty1 (no graphigs to freeze :) ) I was able to send commands like next and step after the breakpoint but there was nothing to see (can't list code, inspect the stack, ect ...)
So any good tips to be able to debug in such situations ?
Thanks
It's typical to have lockups when debugging an X program running on the same server that you're using to debug. For example, if the inferior (gdb terminology for the program being debugged) does a server grab -- whoops, the gdb GUI (or terminal or emacs etc) is locked out.
Your idea of doing more programmatic debugging is a good one, but it's hard to make it all work nicely. As you found, some gdb commands (basically those related to inferior control) don't work in commands. Also, it just isn't nearly as convenient.
You can go further that direction. For example you could use SystemTap to probe the program instead.
However there are also nicer approaches.
One way is to run the inferior using a virtual X server -- a nested one, or one running in a VM. Then you can escape to the "outer" X server for debugging. This will be much nicer.
Another way is to have two computers, and run the debugger on one and the inferior on the other. In a way this is really the same answer, just using a real machine rather than a virtual one.
The question is old, but for anyone that may be struggling with this issue, there is a way to stop the freezing behaviour from happening by disabling the X server grab.
You have to change the config in your IDE to run the program with the following system property:
-Dsun.awt.disablegrab=true
If you are using javaws (Java Web Start) to run the application use:
-J-Dsun.awt.disablegrab=true
instead.
How to make an application to prevent itself from launching from the command line?
I have a binary which should be launched by a daemon; but when somebody tries to launch the binary from command line, I should error out stating "cannot be launched from command line".
Tried googling but in vain.
PS. http://www.daniweb.com/software-development/c/threads/449682/stop-launching-from-command-line
I wanted to check if there are better ways than those mentioned in the link..
I am not sure there is a bullet proof answer (to how to prevent a program to be started from command line). You could consider
testing with isatty(3) that STDIN_FILENO (i.e. 0) is not a tty
try to open /dev/tty (it should fail) see tty(4)
testing with getsid(2) that your are not in the same session than your parent, or starting a new session with setsid(2)
calling yourself daemon(3)
And I am not sure that you always want to reject being started from a terminal. For debugging, you surely want to be able to be started from a terminal. I actually would just warn, not quit, if started from a terminal.
And you probably want to install your program outside of standard paths, maybe in some libexec/ or sbin/ directory.
See also capabilities(7), pty(7), termios(3)
For the record, testing with isatty(3) only works if you are writing that binary files yourself. The method would fail if you are trying to prevent people from starting a third-party binary files.
Generally speaking, to prevent people from starting the specific program(s) from command line, the *nix way is to chown the binary file(s) to be owned by the daemon that launches it, and also to be of owned by the group say no_command_line. Then chmod 705 binary_executables, and put all those people not allowed to run the binary_executables from command line in the group no_command_line.
HTH
I recently downloaded MI library and executed / read some examples code. In all the examples that I saw the implementation was via a separate program like below:
Main Program
Interact with GDB
exec another program
Gather Debug info of the another program
My question is how can we invoke / implement GDB within current thread/program itself i.e. attach this self-execution process.
how can we invoke / implement GDB MI within current thread/program itself i.e. attach this self-execution/ running process to GDB and then tell it to execute step by step
You can't.
Think about it: the very first thing GDB will do after attaching is stop your program, and wait for instructions on what to do next. At that point your program should send GDB the continue command, except it can't because it has been stopped.
Now, if your program is multi-threaded, and you ask GDB to execute in non-stop mode, and you carefully arrange things such that your thread that performs GDB interaction itself is never stopped, then perhaps this could work. I doubt it will work reliably though.
I've coded a program in c for an embedded system (Devkit8000, which is a clone of the well known BeagleBoard) running Angstrom Linux.
The program creates a couple of threads, on of them is responsible of taking pictures with a camera connected to the board, and right now the second thread only moves that images to another path. The program should be running during the whole day, and the only way to stop it is sending a signal.
I edited the crontab to launch the program in a specific hour and to send a signal when it has to stop, the issue is that launching the program in this way cause the process to be killed after some time running, but, if i launch the program manually (through the command line), it works perfectly and dont get stopped.
I have no idea about the reason of this different behaviour between crontab and command line. I've checked the system logs but didnt find anything useful. I've also been reading a little and find that the OS can kill a process if it is using so much resources, but doesnt make sense that this happens in only 1 scenario (crontab vs manually)...
Any clue about what is happening?
Thank you in advance!
The main difference is that running a job through cron invokes a non-interactive non-login shell. The effect of that depends on the default shell for your user. For example, if you are using Korn shell or Bash then your .profile will not be executed, as it would on an interactive login shell. Korn shell 88 will execute .kshrc (the $ENV file) but ksh93 will not.
So, a good start might be to call your program from a script, after first "sourcing" your .profile file:
. $HOME/.profile
Failing that... When you say that the process is "killed", do you get such a message? If so, then that sounds like someone sending SIGKILL, i.e. kill -9. If not, then maybe you could run strace or ltrace to find out at what point it dies.