I have to debug large programs with nested function calls. I would like it s.t. whenever an exception occurs I simply halt the execution at that point, within any function I might be in. Then I can try out different corrections for the error and move on.
While I have been using try except, what I need here is that I can halt inside any function, no matter how nested the call to it might be. So, to do it manually I would have to wrap each function's code around a try-except! like so:
def fun1:
try:
except:
pdb.set_trace()
And this would be very cumbersome to write. Also since whenever I encounter an exception I go straight to the except block, for large functions this would require me to restart from the beginning, which would be time taking. So basically I have this (ambitious) requirement of running each line of code in it's own try-except block, like:
def func1:
try:
line1
except:
pdb.set_trace()
try:
line2
except:
pdb.set_trace()
Is there some automatic, or clever way to rig up such a system?
Thanks in advance.
Any good IDE will have the ability to add breakpoints to debug your code. I personally use PyCharm by Jetbrains jetbrains.com/pycharm. You can add breakpoints and step line-by-line through your code easily. It also automatically halts execution at an exception and you can manipulate values. How are you developing your python code now?
Related
I am using: ipdb (ipdb==0.13.9).
For the with launch_ipdb_on_exception(): line in code-block from answer for Launch an IPython shell on exception
from ipdb import launch_ipdb_on_exception
def main():
with launch_ipdb_on_exception():
# The rest of the code goes here.
[...]
I am getting following warning message:
[not-context-manager] Context manager 'generator' doesn't implement __enter__ and __exit__. [E1129]
What is the main cause of this error? How could I prevent this warning message?
The goal of Python's with statement is syntactic sugar to properly manage external resources to your script such as files, locks, network connections, and others. You have to manage these resources; otherwise, a script will retain those resources forever causing a memory leak. The problem with the regular paradigm of
file = open...
file.write...
file.close()
occurs if an error occurs during the file.write call, then file.close will never be called causing an issue. In Python, there are generally two ways to deal with these issue.
A try...finally construct
A with construct
This second approach provides a [design] pattern to generate setup and teardown code as long as the resource that you are managing works with Python context manager paradigm. The reason for this is due to Python's with clause embodying C++'s well known "resource acquisition if initialization" paradigm (RAII): You need only write context manager classes--that is, classes with two special methods (dunder methods in Python terminology) enter and exit . enter must be callable without arguments. exit must be callable with three arguments: all None if the body completes without propagating exceptions, and otherwise the type, value, and traceback of the exception. This provides the same guaranteed finalization behavior as typical ctor/dtor pairs have for auto variables in C++, and try/finally statements have in Python or Java. In addition, you gain the ability to finalize differently depending on what exception, if any, propagates, as well as optionally blocking a propagating exception by returning a True value from exit.
Hope this helps and good-luck!
I have a function that I am trying to examine. I want to find all callers of this function, but there are a few issues:
I am doing this to understand the code because I did not write it, but I need to know exactly how it behaves
It runs through the STL beforehand, so I can't just use something like callgrind to get it's immediate callers
There is a stack trace of 10+ function calls until you get to actual code that is not in the STL that caused this function to be invoked. But those STL entry points vary, as it is a compare function and calls for is_equal go through a different sequence than those that go through not_equal, etc. I will need to do this for at least 10+ different functions, and I want to streamline this as much as possible.
I want a tool that can dump each unique, full backtrace each time the function is called. Does anybody know a tool that can do this?
I am using gdb and c++ on Ubuntu 14.04.
You can make gdb execute a series of commands each time a given breakpoint is executed, e.g.,
break someFunction
commands
bt
continue
end
The feature is mentioned in gdb scripting: execute commands at selected breakpoint, which has a link to the online documentation for gdb 5.1.7 Breakpoint Command Lists
I have a ruby script, apparently correct, that sometimes stops working (probably on some calls to Postgresql through the pg gem). The problem is that it freezes but doesn't produce any error, so I can't see the line number and I always have to isolate the line by using puts "ok1", puts "ok2", etc. and see where the script stops.
Is there any better way to see the current line being executed (without changing the script)? And maybe the current stack?
You could investigate ruby-debug a project that has been rewritten several times for several different versions of ruby, should allow you to step through your code line by line. I personally prefer printf debugging in a lot of cases though. Also, if I had to take an absolutely random guess at your problem, I might investigate whether or not you're running into a race condition and/or deadlock in your DB.
I have a VB6 application that I'm trying to make log out differently. What I have is a flag in the registry (existing) which states if the application is set to Debug mode so that it would log out.
Within my code I then have lots of if statements checking if this is true. This means that there is a lot of processing time checking if a statement is true, which maybe not much really but as it does it so often it's an overhead I would like to reduce.
The code is full of statements like this
If isDebug = True Then
LogMessage("Log what is happening")
End If
So what I'm looking for is a better way to do this. I know I can set a debug mode within Project Properties -> Make, but this needs to be set prior to building the .exe and I want to be able to set this in production via the registry key.
Consider using a command line argument to set debug mode. I used to do this.
Dim sCommandLine() As String
sCommandLine = Split(Command$)
For I = 0 To UBound(sCommandLine)
' do something with each arg
Next I
You can also persist command line args inside the IDE, so you always have them when debugging. When running outside of the IDE, make a shortcut to the compiled application with the arguments in it.
I do something almost identical to what you have in mind in a lot of my code. Add this:
Sub LogDebug(ByVal strMsg As String)
If (isDebug) Then
LogMessage(strMsg)
End If
End Sub
Then just call LogDebug in your main program body, or call LogMessage directly if it's something you always want to log, regardless of the debug flag.
I'm assuming isDebug is a boolean here. If it's a function call, you should just create a global flag that you set at the beginning of the code, and check that instead of looking at the registry over and over. I don't think checking a boolean is that much of a processing load, is it?
You want to call a function if a runtime flag is set. The only thing I can see that could be faster is:
If isDebug Then
LogMessage("Log what is happening")
End If
But I doubt that either would be the cause of performance problems. Most logging frameworks promote code like that and even put the flag/log level as a parameter to the function. Just be sure that you don't have other places where you needlessly compute a log message outside of the conditional statement.
You might evaluate why you need logging and if the logs produced are effective for that purpose.
If you are looking for a problem that can be trapped using VB error handling, consider a good error handling library like HuntERR31. With it you can choose to log only errors instead of the debug message you are now doing. Even if you don't use the library, the docs have a very good description of error handling in VB.
Another answer still:
Read your registry flag into your app so that it's a session based thing (i.e. when you close and restart the app the flag will be checked again - there's no point in checking the registry with every single test).
Then (as per Tom's post) assign the value to a global variable and test that - far faster than a function.
To speed up logging you may want to consider dimensioning a string buffer in your app and, once it has reached a specific size, fire it into your log file. Obviously there are certain problems with this approach, namely the volatility of the memory, but if you want performance over disk access I would recommend such an approach.
This would, of course, be a lot easier if you could show us some code for your logging process etc.
I'm trying to watch the execution of a VB6 app and I'm running into an issue because once I enter the debugger and then hit Continue, it no longer lets me step through the code until I hit another break point. I want to be able to execute a program without stepping through something until I hit a point where I want to watch it execute. Ideally this would be something to the effect of holding a key down while I pressed a button to 'step into' that function.
Thanks in advance!
[EDIT]: I'm aware that I can use break points to stop the execution. To be more clear, the problem is that I don't know where the execution is going to, so I can't set the break point there (because I don't know where there is). That's why I essentially want to be able to say, 'after this next thing that I do, break, no matter what'. It sounds like this functionality does not exist, but I'm still keeping my fingers crossed.
While the code is running, press ctrl+break (or the 'VCR pause' button in the IDE) then press F8 (or choose 'Step Into'from the Debug menu in the IDE) to continue running the app. The next action will cause execution to break.
Note that the which causes the break will not always be the one you hoped it would be. Particularly annoying is the _MouseOver event which prevents you from doing a mouse down or a timer firing quckier than you can perform your action. Some breaks may even be fatal as regards running your app e.g. where Windows messages have been hooked (subclassing). Also consider there may not be an event handler in code (yet) for your action where it can break. But usually this technique identifies where you should be setting your breakpoint.
There is a Stop statement available for use in VB6 that will drop to the debugger when the statement is executed from code running through the IDE. (Just be sure to remove the all of the Stop statements from the code when compiling a release build.)
There are several techniques you can use.
These two have been mentioned
Using F8 and Shift-F8 to step through the program
Adding Stops (and later removing)
Others
Use a global variable to create a collection. Use it as a stack and have the subroutines you are interested in push and and pop strings. Conversely don't pop anything and you will get a trace.
Use Watches to monitor and break at selection conditions. You can setup just about any condition to break.
Make a Global String and have your procedures set when you enter them. Monitor it through a Watch.
Use Debug.Print in your code. Also Unlike Stop you can leave these in without effecting the production code.
Use the File System Object to create a text file to act as a log.
Sometimes problem only occurs in the Complied version then you need to use MsgBox or log to a text file. MsgBox can alter the behavior of complex user interactions with forms.
These are all techniques I used in debugging an application. If I had to monitor an application I would use Debug.Print. If that doesn't do the trick compile then log to a text file.
If you have something really complex going on then I recommend moving all your code out of the events into classes implementing a Command Pattern. Your commands classes should interact with the form through and interface.
In the Execute method of the command classes you will something like
<save the current state>
<Do your original code>
<save the modified state>
<push the command onto a stack>
What will happen is that you wind up with a list of all the commands you have executed (even things like mouseover) with the state they encountered and the modified state. You can then examine each object in turn to see what is happening. This is nearly the equivalent of creating Undo/Redo
Note however things like MouseOver can push a lot of classes on the command stack so you will have to structure your tests carefully or be overloaded with information. Remember you can always skip pushing the command onto the stack.
The downside of using commands is that you gone beyond debugging into redesigning. You will to decide whether the problem is worth doing this.
You can press the F8 key to step through the code line by line. Alternatively, you can press SHIFT-F8 to step through line by line.
F8 will step you in to a function, where SHIFT-F8 will step you over the function. If you click on the DEBUG menu in the VB IDE, you will see other options too.
EDIT:
You can also put a permanent break point in your code by using:
Debug.Assert False
By doing it this way, the 'breakpoint' is saved in your code. When you compile the app, debug code is ignored.