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.
I built a (customized) 1.8 HotSpot VM in Netbeans 7.2 using GDB 7.4 which works for executing Java programs. I want to debug a SIGSEGV that the program produces by calling a native function called by JNI that corrupts an object header.
However, I have some problems debugging the HotSpot VM: I have several breakpoints before the call to the main function in java.c. Sometimes, they trigger and sometimes the main function executes without all the breakpoints halting before. The most far I can get is
/* Invoke main method. */
(*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs);
After that, a step-in runs through the whole Java program, eventually triggering the SIGSEGV. The call is leading to the JNI API so I included the "hotspot/src/share/vm/prims" directory to the source dirs in the debug section. However, I could not see any effect. Does anybody have an idea how I can step into the C++ method calling the Java main method?
When the SIGSEGV causes the Netbeans debug view to stop, the call stack shows the expected call stack. However, instead of the C++ code it just shows assembler code while displaying the names of the C++ classes. The initial caller is "?? ()". Is there some way to see the C++ code or do I have to manually map the assembler code to the C++ code? I read a great article by Volker Simonis where he describes that such unknown frames relate to generated code. However, I'm still puzzled that the consecutive caller frames show class and method names. Is it a problem with source lookup or simply relates to the first unknown frame?
Did you compile hotspot in debug mode, i. e. make all_debug? If hotspot is optimised than code may be run in different order than it's in source file, and some symbols can be stripped out, preventing debugger to give you meaningful info, or setting a breakpoint.
Compilation of my code in both modes debug and release is successful. Debug mode execute and works fine, but when i execute release mode, it says "the application was unable to start correctly 0x80000003".
What is this error and why debug mode works fine but not release.
DLLs for debug and release are present in the same directory name "bin". "lib" for both modes also placed in the same directory.
I tried to solve it many ways but not succeeded ? Guide me how to solve this issue? Thanks.
why debug mode works fine but not release
Thre can be many reasons why one build works while another doesn't. The shape and size of data structures can be different because of #ifdef or because the compiler emits different code, the code being executed can be different - again because of constructs like #ifdef or because of the code the compiler is emitting.
That can matter when you've got code with a bug in it. Let's say you've got a bug that miscalculates the length of an array (or the size of a structure or whatever). You do some pointer arithmetic and write some data into memory using that pointer - only you're writing to the wrong place. Whether that mistake breaks your program may depend on what was in the memory you overwrote.
If you're lucky your program crashes almost immediately because what you overwrote was important to some code executed immediately after your bug. If you're only a little bit lucky your program crashes some time later in a completely different part of your program because what you overwrote was important to code far away from your bug. If you're really unlucky your program doesn't crash at all until several years later when a completely unrelated change moves things around in memory so now what you are overwriting suddenly is important.
There are lots of other possible causes of what are sometimes called Heisenbugs
What is this error
One place to look for errors like 0x80000003 is the file WinError.h which you'll find in the SDK you are using (either the one that came with Visual Studio 2010 or one you installed later). Look in WinError.h and you'll find that that E_INVALIDARG is defined to be _HRESULT_TYPEDEF_(0x80000003L).
That doesn't necessarily help though because we we don't know enough about what is returning that error or why it is returning that error or even that your 0x80000003 is in fact an E_INVALIDARG - it could be some other error with the same value, or some piece of code mis-using E_INVALIDARG or something else.
Another possibility is that 0x80000003 is a hard-coded breakpoint exception being thrown - most likely because your program has got to one of those "this should never happen" places where the only thing that makes sense is to throw an exception and crash. If you look in NtStatus.h (in the same place as you found WinError.h) you'll find that STATUS_BREAKPOINT is defined to be ((NTSTATUS)0x80000003L)
how to solve this issue
The trick is to figure what is causing the 0x800000003 (and where in your code it is happening) so you can narrow down why it is happening. Most likely it's an exception but why jump to conclusions?
You can run a release build inside the debugger just as you would run a debug build - that is, build the code using the Release target and then press F5 or Debug | Start Debugging. Look in the Output Window and you may see some information that will help you interpret the error.
You can also use the Debug | Exceptions menu to add a new Win32 Exception with the value 80000003 and set that up to break when thrown rather than to break when unhandled. That way you should stop in the debugger when that exception is thrown (if it is in fact thrown).
Of course it could be that even running your program within a debugger is enough to change things so your problem doesn't occur.
I have a strange problem, I hope you can help me.
I write a program in C++ Builder 2009, when I run the program without debugger I see an Exception raised. bun in debugger never exception raised and I cant find the exception point.
And Also I enable the CodeGaurd in C++ for Finding the problem but the Exception never raised, If I disable codeGuard the exception will be here again.
I use OpenCV and some Delphi units in the program.
And when I compile it I see more than 2 millions of code line compiled.
Thanks in advance for your attentoin.
A few things too look at:
in the IDE options, make sure you are not ignoring some exceptions
debug builds MAY have memory variables set to NULL on run, release builds will not. Make sure you are running the same build (Debug) in both the IDE and without.
Ignore the line count that is displayed, its all those .hpp files that holds the vcl headers.
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.