I'm currently in a Python interactive interpreter session. I have a function that I know is doing something funky, so I want to step through it in a debugger session. I know the file name and line number of the function.
Is there any way for me to now set a breakpoint in the start of that function, then run it and step through it? Without having to open an editor, locate the file, locate the function, manually insert import pdb; pdb.set_trace(), saving the file, then go back to the interpreter, reload the module the function came from and running it? Not to mention that if I forgot to remove the pdb trace that'd spell trouble later.
Summarizing the question: If I'm in a normal Python interpreter session (or iPython), is it possible to set a breakpoint somewhere and start debugging, without having to actually edit in the code pdb.set_trace() somewhere?
I can't believe I missed this, but I just glanced over the pdb documentation a second time and realized that all the run* functions do pretty much exactly what I want. They don't let me set a specific line as a breakpoint, but I can pass the function and the arguments I want to use, and it will break on the first line of the function:
import pdb
pdb.runcall(my_wonky_function, "arg1", "arg2", *myargs)
Well actually it broke at a mystical location called "EOF":
(Pdb) list
[EOF]
and I had to step twice before I got to the first line of the function, but that's hardly a problem.
Related
The basic interface while debugging a basic c++ file with gdb in vscode editor is something like this:
notice the line no. 133 , it contains a function call whose value is not stored in any variable, and it results into a file path somewhere in the user's directory. How do we analyze such return values?
My first question is:
Is there a way to watch this return value in vscode without having to store the return value in any variable?
Secondly,
If it's not possible to see it in vscode, is there a way to do that in the gdb debugger? Since vscode seems to be using the gdb internally, maybe there's a way to setup the settings.json using gdb's flags? If anyone knows, please do mention it.
I have written a Fortran code for being compiled as a '*.DLL' file.
The program which reads that file is a Finite Elements Method software named Plaxis, I already achieved to generate the '*.DLL' file in Visual Studio and Plaxis recognizes my model but the model does not work fine.
I would like to evaluate all the variables involved in my code and the procedure that Plaxis is using to read them, but when I use commands like "write(*,*) 'variable'" Plaxis does not show me what I asked in the source code.
Probably you want to open a file and write to that for debug logging, because presumably Plaxis doesn't run with standard output connected to anything useful. Or maybe it would if you just ran Plaxis from a command line window?
It's not going to create a dialog box for you.
But anyway, another option would might be attach to Plaxis with a debugger, and set a breakpoint in a function in your DLL. Then you can single-step your code as called by Plaxis.
Or you can write your own test callers and write unit tests for your functions, making them easy to debug. This could work well if your function just gets an array + size as args.
If instead it passes some wrapped object that you need to call special functions to deal with, then maybe make another version of your function that does just take an array so you can call it from a simple test caller.
I have a large source tree with a directory that has several files in it. I'd like gdb to break every time any of those functions are called, but don't want to have to specify every file. I've tried setting break /path/to/dir/:*, break /path/to/dir/*:*, rbreak /path/to/dir/.*:* but none of them catch any of the functions in that directory. How can I get gdb to do what I want?
There seems to be no direct way to do it:
rbreak file:. does not seem to accept directories, only files. Also note that you would want a dot ., not asterisk *
there seems to be no way to loop over symbols in the Python API, see https://stackoverflow.com/a/30032690/895245
The best workaround I've found is to loop over the files with the Python API, and then call rbreak with those files:
import os
class RbreakDir(gdb.Command):
def __init__(self):
super().__init__(
'rbreak-dir',
gdb.COMMAND_BREAKPOINTS,
gdb.COMPLETE_NONE,
False
)
def invoke(self, arg, from_tty):
for root, dirs, files in os.walk(arg):
for basename in files:
path = os.path.abspath(os.path.join(root, basename))
gdb.execute('rbreak {}:.'.format(path), to_string=True)
RbreakDir()
Sample usage:
source a.py
rbreak-dir directory
This is ugly because of the gdb.execute call, but seems to work.
It is however too slow if you have a lot of files under the directory.
My test code is in my GitHub repo.
You could probably do this using the Python scripting that comes with modern gdb's. Two options: one is to list all the symbols and then if they contain the required directory create an instance of the Breakpoint class at the appropriate place to set the breakpoint. (Sorry, I can't recall off hand how to get a list of all the symbols, but I think you can do this.)
You haven't said why exactly you need to do this, but depending on your use-case an alternative may be to use reversible debugging - i.e. let it crash, and then step backwards. You can use gdb's inbuilt reversible debugging, or for radically improved performance, see UndoDB (http://undo-software.com/)
If I do C-u M-x recompile inside a buffer that's not the *compilation* buffer, (i.e. the source file for instance), I get this error - "Wrong type argument: consp, nil" after it prompts for the compilation command. Why is this? I want to run recompile interactively as comint works, sometimes outside the compilation buffer. How do I do this?
Try using emacs -Q, just to be sure (yes, I know you said you commented out all of your init file, but just to be sure -- and it's a lot easier to do than comment-out everything).
Next, set debug-on-error to t -- You can do M-x toggle-debug-on-error to do that, if you prefer.
Next, provoke the error and look at the debugger *Backtrace*. It will show you not only which function raised the error because it expected a cons and got nil instead, but also what function called it, passing the bad argument. And so on down the stack.
If necessary, you can click mouse-2 on functions on the stack (at the left, to see their source code. Or put the cursor on them and use C-h f to see their doc -- in particular, what arguments they expect and what their return values should be.
In this way it's pretty easy to find the code that is the culprit. (Most likely, in spite of what you said, it is some non-vanilla Emacs Lisp code you loaded somehow.)
Also, state your emacs version : M-x emacs-version. If you are using a development snapshot then the problem could come from vanilla code (i.e., emacs -Q); otherwise, that's not so likely.
Also, you say you get the error after it prompts you. Immediately after it prompts, before you type anything? After you type a command name and hit RET? Try to be more specific.
Update after your comment:
Load library compile.el (not .elc). Then do M-x debug-on-entry recompile, then step through the debugger using d when function recompile is entered. What you are interested in is when compilation-start is called (applied to its args).
It seems that the value of compilation-arguments that is passed to it is no good. The command name you enter at the prompt becomes the first of the list of compilation-arguments. The others are taken from when you last invoked compile: recompile just reuses the same arguments (except the command name): (mode name-function highlight-regexp)mode name-function highlight-regexp).
However, be aware that compilation-arguments is buffer-local. So if you changed to a different buffer then its value is likely not what you need. You need the value from your last compile, so you should do the recompile in the same buffer where you did compile.
(FWIW, I don't use (re)compile myself, as I don't develop software anymore. I just took a look at the source code.)
Such kind of errors usually depicts a problem with your configuration. Try to investigate messages buffer output. There can be some clues there.
And of course, it is normal to call a recompile command from a buffer with your code. It is a convention to bind it to C-c C-c.
I am wondering what difference it makes to the debugger (Intellij IDEA + Scala plug-in) when I debug Scala code and not Java code. To my understanding, a debugger is tightly coupled with the language i.e. a Java debugger can not handle Scala code but apparently the JVM is the center of attention here meaning as long as it is byte-code, any debugger would do. right ?
IMPORTANT UPDATE: The problem was to give an example of how a byte-code debugger may be limiting for Scala. Assume a break point is reached and I don't want to go to the next line but I want the debugger to evaluate an Scala expression in the context of the application (e.g. I like to call an operator method from a singleton object). The debugger is stuck because it can not understand Scala. I have to do the transformation myself and input the resulting Java to the debugger.
The problem is that only "breakpoint stuff" could be handled in byte-code level. What if you want to put an expression under watch? Debugger has to understand Scala to evaluate the watched expression,right? This time I'm sure I'm right. Vengeance is mine, Saith the Lord ;-)
Short answer your assumptions are wrong.
The reason is the debugger does not care what language your debugging. It stops at breakpoints which in turn include the line of a particular source file. Note that the source file is merely text for you to read - the debugger never scans the source files. If you change the spot where source files are to another directory with a text file in the right directory w/ the right filename as a breakpoint that has been set, the debugger will happily show it when the breakpoint happens. Everytime you set a breakpoint your ide is telling the debugger hey scan this class for any byte code on this line and stop when you hit it. This of course does not work if your ide is attempting to compile the same text file into a class file - however it will work if you create fake text files as source for a jar file and do the source file mapping thing.
If one thinks about it, writing a simple template and compiling it while support debugging is not that difficult. Simply use asm to create all the print statements and tell asm this print statement is from the template file on this line. After that you can add more clever stuff while keeping things debuggable.