I'm debugging my linux kernel module. It causes deadlock and i'm trying to figure out how. I'm using vmware + gdb. The idea is to hook the function and log backtrace into the file. I'm trying the following:
(gdb) br _raw_spin_lock
Breakpoint 5 at 0xffffffff815eb700: file kernel/spinlock.c, line 136.
(gdb) commands 5
Type commands for breakpoint(s) 5, one per line.
End with a line saying just "end".
>silent
>bt
>continue
>end
but continue doesn't work here. If i replace bt with echo 1 it works. Is there way to log information every time the function is called?
Thank you.
Most likely you are hitting gdb pagination prompt.
https://sourceware.org/gdb/onlinedocs/gdb/Screen-Size.html
Run this before setting the breakpoint
set height 0
You don't say why it doesn't work. What exactly goes wrong?
Normally this kind of thing works fine. Putting "continue" into a breakpoint's commands is something I've done routinely for years. It isn't without problems (it interferes with "next") but if you are just doing logging or the like, it works great.
One guess would be that the "bt" is failing with an error. This would cause the commands to abort and, I believe, the inferior to stop at the breakpoint. Then the question is, what exact error message is emitted? Or perhaps you're hitting pagination. Or maybe some other thing I haven't thought of :-)
If it's an error, one possible option might be to limit the backtrace.
Related
I just accidentally typed stop instead of exit in a bash script. When I execute it my Xubuntu went to the login screen and when I logged in, everything was closed and it was like I just started the computer.
I then went to my Ubuntu on a virtual box and executed stop in the terminal. Then some windows was closed and some frames around other windows disappeared.
I'm a Linux noob but when I looked at the stop command info it looks like you need to have an argument to use the stop command.
Is this just a bug or is this supposed to happen? If it's supposed, then I'm really curious of whats happening. My guessing is that it will try to kill all ongoing processes.
I'm new here so I hope this it not a stupid question and its really hard to google on a common word like stop :/
man stop should tell you what it does. E.G. http://manpages.ubuntu.com/manpages/precise/en/man8/stop.8.html
I think it should tell you it needs an argument for a name of a job to stop.
However it appears from what you describe that it's stopping the X11 window manager?
How do you go about debugging a non-responsive python/PyQt application in PyCharm?
I am an experienced programmer, but new to all thing python. I have been given a large application (36,000 lines), which works under Windows, to port to Linux.
Having made just a handful of changes for OS-specific stuff, when I run the application it comes up with its main window. But then after a few seconds it becomes dimmed, and when I close the window I am asked to confirm to end "the window is not responding".
(Aside: On a whim I decided to try running the app via sudo, and surprisingly it works fine. I have tried doing strace running as root versus non-root, but I'm fairly sure there is nothing obvious in the way of file accesses/permissions etc. that differs. This may be a clue, but just as likely to be a red-herring, e.g. if it's an "uninitialized variable".)
If I debug it inside PyCharm, at that point I expect to click the "Pause Program" button, so that I can get a trace back and begin to see where it is in the code, and start stepping or whatever. However, that button does nothing at this stage? Maybe it only "works" when on "a python instruction"?
If I force a core dump (from the keyboard) and examine with gdb, I can see that the stack frame shows it is way down inside libQtCore/libQtGui, in processEvents on a call to read.
So how do I begin to go about debugging why it is (presumably) busy doing something at this point, or at least not responding? Any tips would be welcome. I do hope this question will not fall foul of SO's "too general" policy, any tips to get someone going on debugging a "non-responsive" program would be welcome.
To answer my own question, since no responses seem to be forthcoming.
In this case, the problem turned out to lie in a file which is imported into other files, named pyperclip.py. That had code outside of any function, and in a path through the source executed under Linux but I think not under Windows, which included:
app = PyQt4.QtGui.QApplication([])
cb = PyQt4.QtGui.QApplication.clipboard()
Clearly some attempt to gain a clipboard object. For whatever reason, this appears to work when run as su, but when run as the logged on user it causes the whole application to "hang". Removing those two lines solved the unresponsiveness.
In terms of what I learnt from this for debugging unresponsive applications: you need to debug not from the entry point of the program, as I would have expected, but rather right from the start of each file, and actually step into each import line just in case it is executing some initial code. Horrible!
I am working on a Tcl project where a certain procedure will run continuously. user can abort that procedure anytime using some Key-Combination. So basically, I need to trap the signal within Tcl code. So far, everything is done except one problem.
I am using Ctrl+Z i.e. SIGSUSP signal (SIGTSTP in case of Tcl) which technically does the job.
signal trap sigtstp onAbort
But, pressing Ctrl+Z immediately returns the Shell prompt, rest of the output from the program comes after that and when output comes to an end, no shell prompt returned (as it is already returned before). I need to press Enter again to get the prompt.
Following is the case I am refering to. You can see the prompt (polaris#ubuntu:~$) is returned in between output of the main program.
Also as output of pressing Ctrl+Z, it returned [40]+ Stopped, which is bit annoying. Can I avoid this ?
Can I avoid this whole problem using some other key-combination i.e. signal ? Or can I avoid this with Ctrl+Z also by tweking something ?
NOTE: I have tried using Ctrl+C. I got the exactly expected behavior with that. Unfortunately I can't use Ctrl+C as it is used for some other functionality.
Cz causes the shell to send the current foreground process a SIGSTOP(19). This signal cannot be caught or ignored and so your program will receive it and run the default handler. This is not killing the process as your question suggests you're trying to do. This only suspends it and you can bring it back into the foreground using fg on most modern shells.
Looks like you're out of luck. However, you might be able to rebind the keychord at the level of the shell. This is outside your program though and your end users don't have control over it. (Cf. https://superuser.com/questions/378018/how-can-i-do-ctrl-z-and-bg-in-one-keypress-to-make-process-continue-in-backgroun)
Also, if your program relies on user inputs for various actions (since you suggest that C-c does something else), perhaps you should make it a full fledged CUI application using curses or something?
I'm using Microsoft Visual C++ 6.0 and trying to debug someone else's program. I tried to use printf statements but for some reason, these statements are not shown on the screen as the program runs. I am able to use fprintf to print these statements to file, but this is useless when the program crashes in the middle of execution, as the file would be empty then.
How can I force some output to screen?
To force output to the screen, please see the first section below. The second and third options below are also good for debugging program crashes like these.
Using printf with fflush (refinement of Vishal Kumar's answer)
Vishal Kumar's answer worked for me, but I had to do a little research to find out how to use fflush. I had a problem where my program was crashing "in the middle" of a printf statement which did not make sense. Here is my refinement of his answer. In cases where a debugger is difficult to use (e.g. multithreading), you can use fflush after every printf (or fprintf) statement. For example, "pepper your code" with:
... // code
printf("Part 1 executed successfully");
fflush(stdout); // flushes the stdout buffer
... // further code
printf("Part 2 executed successfully");
fflush(stdout);
... // repeat as necessary
Run, observe the output, and put more print statements between the last statement that prints, and the first statement that doesn't print, until you isolate the problem.
Debugger
If you are able to use a debugger, it is a more efficient choice than peppering your code with output statements as described above, but there are cases where you have to resort to that.
Valgrind
If you are using Linux (which I gather you are not because it is in MS Visual C++), valgrind is another option to see where your code is crashing (and for detecting memory leaks). If your code is compiled for debug, if your program is called "myProgram", you can just call from the terminal window as follows:
valgrind myProgram
Besides using top, is there a more precise way of identifying if the last executed command has finished if I had to check in a separate session over Putty?
pgrep
How about getting it to run another command immediately after that sets a flag.
$ do_command ; touch I_FINISHED
then when the command finishes it'll create a file called I_FINISHED that you
can look for.
or something more sophisticated that writes to a log file if you're doing it
multiple times.
I agree that it may be a faster option in the long run to have your program write to a log file or create a notification. Just put it at the end of the executed code, past the part that you suspect may cause it to hang.
ps -eo cmd
Lists all processes, and displays the command line, as 'typed' when the command started, so you will be able to tell your script apart from anything else running written in Perl.