Is there a way to tell pyCharm that it should skip framework code? The debugger should skip all lines which are not from me.
In my case it is very easy to tell which code I want to debug and which not:
Code in virtualenv lib should be skipped
Code in virtualenv src should be debugged.
If I press F7 (Step Into) it should skip all lines which are not from my code base.
[Update May 2015: introduced in PyCharm 4.5]
There are two new features now, one of which is the one you asked for, but I mention the other one as well because it is topically very close.
From the 4.5 release notes:
Step into My Code
Stay focused on your code by telling the debugger to step only through your project code, as opposed to stepping through the library sources.
[...]
Ignore Library Files
The debugger is improved with the new 'Ignore library files' option. Use it to have the debugger stop inside your code in case the exception is raised in a library module, instead of stopping inside the library code.
[Update after learning about blackboxing libraries in debugging]
In this answer it is mentioned that you can add the modules to ignore into "the dict DONT_TRACE in /helpers/pydev/pydevd.py"
And there is an open issue on the issue tracker.
[original answer]
It is not possible to skip code like that, but you can flexibly switch between walking through the code line by line and making bigger jumps in a running debug session by simply adding another breakpoint (while debugging - break points can be changed in a running debug session) at the position after the library code you want to skip and press 'Resume Program' in the Debugger. The library code is skipped and you are back in your code.
You might also want to use conditional breakpoints to make sure that the program breaks into the debugger exactly when the program is in the state that you desire: right click on a breakpoint and enter a condition that has to evaluate to True in the context of that line.
Related
Is there a way to run my .fs file with either a breakpoint or a command like System.Diagnostics.Debugger.Launch() in it so that I can use FSI to examine values, apply functions to them, plot them, etc.?
I know this question has been asked before but I tried the answers and could not make them work. Clear instructions or a link to a write-up explaining the process would be of great help not only to myself, but also, I believe, to all beginners.
Unfortunately, you cannot hit a breakpoint and jump into FSI. The context of a running .NET program is quite different to that of an interactive FSI session and they are not compatible enough to just switch between one or the other. I can understand an expectation of this kind of debugging when coming from other dynamic/interpreted languages such as JavaScript, Python etc. It is a really powerful feature.
As you have already noted, you can use the VS immediate window but you need to use its C#-like syntax and respect its limitations. Also, since it's not F#, you need to understand the F# to .NET conversion in order to make full use of it.
If you use Paket for dependency management in your project you have another option: Add generate_load_scripts: true to your paket.dependencies. This will give you a file like .paket\load\net452\main.group.fsx, which you can load into FSI to get all of the dependencies for your project. However, you are still responsible for loading in your own source files and building up some state similar to what is found at your desired breakpoint.
To hit a break point, in visual studio or visual studio code, you just click to the left of the line number you want to set your breakpoint. This is very much a supported feature in .fs files.
I'm learning how to use a debugger and wonder if I'm missing the obvious.
My simple script includes two functions that work OK. The main code calls them repeatedly. Is there an easy way to single-step through ONLY the calling code, while the functions and the libraries they use run at normal speed?
I'm using python 2.7 and pyscripter, but I'd imagine that people might want this in other debuggers and languages. Perhaps there's a way to mark sections of code as trusted, and single-step the rest?
With search help from Dani's comment, I found several great explanations elsewhere on Stack Overflow. My favorite, from polygenelubricants on this Eclipse question:
When debugging lines of code, here are the usual scenarios:
(Step Into) A method is about to be invoked, and you want to debug into the code of that method, so the next step is to go into that method and continue debugging step-by-step.
(Step Over) A method is about to be invoked, but you're not interested in debugging this particular invocation, so you want the debugger to execute that method completely as one entire step.
(Step Return) You're done debugging this method step-by-step, and you just want the debugger to run the entire method until it returns as one entire step.
(Resume) You want the debugger to resume "normal" execution instead of step-by-step.
(Line Breakpoint) You don't care how it got there, but if execution reaches a particular line of code, you want the debugger to temporarily pause execution there so you can decide what to do.
Eclipse has other advanced debugging features, but these are the basic
fundamentals.
Can I set the Visual Studio debugger to break on thread creation?
(Note this is not the same as breaking on context switch as asked for in this other question: Can I set a breakpoint in Visual Studio (c++) to break on a thread context switch?)
I've found a way to do it. While googling I saw the opposite question:
Is it possible to break on thread exit with specific error code?
I put a breakpoint at the function RtlExitUserThread, after that I realized that all threads was creating with the function RtlUserThreadStart, so put another breakpoint to that function and that's all :)
As explained by #George, there are two functions you can break on. If you want to find out what creates the new thread you should break on thread creating WINAPI function calls such as CreateThread or _beginthread(ex). If you want to break into the start of the newly created thread (on the call stack of that thread itself) you should break into RtlUserThreadStart.
However, there are two prerequisites to be able to break into either of these:
1. Symbol downloading from Microsoft Servers needs to be enabled
For the breakpoints to work the debugger needs to know some basic symbol information of the native dlls. Make sure symbol loading from MS servers is enabled (Tools -> Options -> Debugging -> Symbols)
2. You need the actual stdcall signatures of the target functions
For some reason even with enabled export loading VS was unable to find the functions I needed to break on for me. So I went checking what the actual signatures are. This can be done by using the dumpbin cmd line tool of VS, or by running a short test on the code:
void* ptr = CreateThread;
Running this code in the debugger reveals the address and signature of the CreateThread for example which is _CreateThreadStub#24 for me (Win7 32-bit application). For RtlUserThreadStart it was ___RtlUserThreadStart#8 for me.
3. Setting the breakpoint
Now it's as easy as choosing Debug -> New Breakpoint -> Break at Function. For the function name you put either _CreateThreadStub#24 or ___RtlUserThreadStart#8 and leave the rest be.
This then triggers when a new thread is being created.
Observation
_CreateThreadStub#24 seems to cover the CreateThread, _beginthread and _beginthreadex functions.
If you know the thread is being created by the managed Thread class, then a simple solution would be to put a breakpoint on its entry (by going to the Breakpoints window, clicking New->Break at function and marking Thread.Start).
Otherwise, as Hans said, you would have to use a more complex solution like mdbg, or using a open-source implementation of CLR profiler (like SAE) and putting an "asm int 3" instruction in the ICorProfilerCallback::ThreadCreated method.
Also, if you have VS2010 Ultimate, you could just look up the Thread Created event in Intellitrace events, and possibly get the information you need from there (though this will not break when the thread is created, but rather give you some info about the stack trace/variable values at the time it was created, in retrospect).
Yes, the debugger gets a notification for it. No, the UI doesn't allow you to tell it to break on that notification. If this is for managed code then you could use the MDbg sample and modify it.
There are at least 2 potential things you could mean when you say you want to break on thread creation:
Break inside the creating thread BEFORE the new thread has been created
Break inside the NEW thread before the user-provided function is called.
For the first option, you'll want to break in CreateThread, _beginthread, or _beginthreadex.
For the second option, you'll want to break in RtlUserThreadStart or BaseThreadInitThunk to catch the new thread early in its execution before user code gets called.
Unfortunately, Visual studio won't break in those functions if you create a breakpoint with the function names I've listed above, at least not by default. The problem is that for native debugging, it doesn't load DLL exports by default, and without that, the debugger has no idea where to find the names I've provided above.
Before you start debugging, in Visual Studio go to tools, options, debugging, then expand the debugging options tree in the left pane. Then click on "native" and check "Load DLL Exports". Then you can start debugging your executable again.
After that, you should be able to create a breakpoint on any of the functions I mentioned by typing in the name. You may or may not need to specify the DLL the function is in by creating the breakpoint with the name as follows:
{,,kernel32.dll}CreateThread
or
{,,ntdll.dll}RtlUserThreadStart
I got this information by starting here:
https://blogs.msdn.microsoft.com/reiley/2011/07/26/debugging-tips-for-multi-threaded-application/
and doing some experimenting on my own. I know this is a response to an old question but I hope this saves other people some of the pain I've had when trying to debug crashes that happen immediately upon thread startup.
You can set a breakpoint at the first call to CreateThread (maybe you insert a fake call for this purpose).
When hit, change from Source Code View to Disassemly View and step into the call. Go through the ImportLib-Code and set a breakpoint. Not perfect, but it works.
Googling this yields lots of entries on HOW TO step through Framework code. I'm trying to find out how NOT TO step into.
First check: Yes, "Enable Just My Code" is checked in the Tools->Options->Debugging. That is supposed to keep VS2010 from looking for source code when you are stepping through a framework function (or anything else that you don't have the source to, as I understand it.)
It's not. I'm trying to step through my code, using F11, and, if I get careless and don't switch to F10 (to step over a function call) when I get to a function that is in a library, then it throws up a dialog asking where the source for that call is, and when I cancel out of it (since I don't have the source), it aborts my Debug, and I have to start all over.
How can I avoid this behavior. As I understand the documentation, this is NOT the way it is supposed to work. And where do we go for support when it's not working?
You can do this by simply not loading symbols for the framework.
In the Symbols window, there is an option for "Automatically symbols for:" depending on the option you choose you can explicitly exclude those modules, or only specify your own modules.
I assume you are using the All modules, unless excluded option, so you should exclude the framework modules.
If you actually own the framework you can also add a StepThrough attribute to any framework functions you want to step through. See http://msdn.microsoft.com/en-us/library/system.diagnostics.debuggerstepthroughattribute.aspx.
I have recently edited a fellow student's data collection software to my specifications. The program works fine when I run within Visual Basic 6, however ideally I would like to compile the program into an .exe file so I can run it from any PC. However, when I select the option to turn it into an exe, I get the following error while its compiling:
Compile Error: Sub or Function not defined.
I was curious why my program will run from within Visual Basic, but can't compile into an exe. Any fixes/suggestions would be greatly appreciated!
You must just be running the app in the IDE by using Start (F5) - this does not do a full compile so won't catch all compile errors. I suggest you always use Start With Full Compile (Ctrl+F5) - then it will show you where the errors are.
You can create a custom control bar button to do the Start With Full Compile - saves typing CTRL+F5 all the time.
at the begining of every file, write "option explicit". This changes vb behavior from weak typed to strong typed.
What this means is that when you put a string into an integer, then the vb will tell you right away, or at least when you press "run". In a weak typed mode, the program will run until it encounters a fault, like "Sub or Function not defined" then crash.
When you compile into an "exe", vb needs to do extra sanity checks much like "option explicit" would do. This is why you don't see the problem while normal execution. It is still there, lurking, but you probably don't execute the problematic line.
It is very important that you use this keyword in every vb source file you have, otherwise you'll see problems like this all the time.
It allows you to run the program even though it won't compile due to the Compile On Demand feature the IDE supports. As noted in other posts you can CTRL-F5 to do a full compile, or you can go into Options --> General and turn off Compile On Demand...(saves a lot of CTRL-F5s)