I am relatively new to IntelliJIdea. I am running version Ultimate 2019.2.
I am doing a multi-threaded debugging and it seems like IntelliJ suspends all threads once one of the breakpoints got hit. This means, at a given time I can work with one breakpoint only, I do not have the visibility into how my multi-threaded app is behaving.
In Eclipse I would see all suspended threads and I could've worked with any breakpoint I wished in any of suspended threads.
How can I configure smth like that in IntelliJ?
I have seen that I can select a breakpoint and then select a behavior for it: stop all threads or stop only a thread on which it was invoked. That's nice.
But I do have several dozens of breakpoints and I do not want to go back and change that behavior for each breakpoint separately. Can I configure this behavior globally??
Pls, advise. This is super annoying.
Alright, I have figured it out: when changing suspension behavior for a given breakpoint, there is a button Make Default that allows setting this behavior for all new breakpoints created after the change. Breakpoints created before the change will have their behavior unchanged.
Related
I've written a simple IRC-proxy for a single client with a built-in bot.
It spawns two threads, one reading from the client and feeding the server and the other doing the oppisite.
So far it works correctly. But if I put a breakpoint within the run()-methods of the thread-object, the IDE will never stop there. Breakpoints in the main-thread stop correctly.
What am I doing wrong here?
You have the change the suspend policy for breakpoints to thread as documented here.
You would do this like so:
The following shows usage of the thread suspend policy. Notice how the Console does not have anything printed on it and also that ALL the threads have stopped on the breakpoint:
The following shows the same breakpoint with the default Suspend All policy and how changing it to Thread on-the-fly results in stopping any threads that hit that breakpoint after that change:
I have been asked to debug, and improve, a complex multithreaded app, written by someone I don't have access to, that uses concurrent queues (both GCD and NSOperationQueue). I don't have access to a plan of the multithreaded architecture, that's to say a high-level design document of what is supposed to happen when. I need to create such a plan in order to understand how the app works and what it's doing.
When running the code and debugging, I can see in Xcode's Debug Navigator the various threads that are running. Is there a way of identifying where in the source-code a particular thread was spawned? And is there a way of determining to which NSOperationQueue an NSOperation belongs?
For example, I can see in the Debug Navigator (or by using LLDB's "thread backtrace" command) a thread's stacktrace, but the 'earliest' user code I can view is the overridden (NSOperation*) start method - stepping back earlier in the stack than that just shows the assembly instructions for the framework that invokes that method (e.g. __block_global_6, _dispatch_call_block_and_release and so on).
I've investigated and sought various debugging methods but without success. The nearest I got was the idea of method swizzling, but I don't think that's going to work for, say, queued NSOperation threads. Forgive my vagueness please: I'm aware that having looked as hard as I have, I'm probably asking the wrong question, and probably therefore haven't formed the question quite clearly in my own mind, but I'm asking the community for help!
Thanks
The best I can think of is to put breakpoints on dispatch_async, -[NSOperation init], -[NSOperationQueue addOperation:] and so on. You could configure those breakpoints to log their stacktrace, possibly some other info (like the block's address for dispatch_async, or the address of the queue and operation for addOperation:), and then continue running. You could then look though the logs when you're curious where a particular block came from and see what was invoked and from where. (It would still take some detective work.)
You could also accomplish something similar with dtrace if the breakpoints method is too slow.
Edit : If you're seeing this same problem (and you're accustomed to NOT seeing this under VS2010) please comment below so I know it's not just me - but be sure to check Han's answer to make sure none of those scenarios appear...
I've been updating my app to run with .NET 4.5 in VS2012 RTM and noticing something that I don't quite understand and that is unexpectedly green highlighted statements (instead of yellow).
Now I'm well aware of what this is supposed to mean, and the IDE is even showing me a little explanation tooltip.
This is the next statement to execute when this thread returns from
the current function
However there's absolutely nothing asynchronous or thread based about this code. In this simple example I'm sure you'll agree that string.ToUpper() won't be off in another thread. I can step through the code no issue.
There's nothing else going on and I am on the main thread as you can see here.
I am using async and await and MVVM-Light (the above method is the result of a RelayCommand) but I still get this behavior even when the code path is directly off an event handler such as PreviewKeyDown.
If I create a new app I cannot duplicate this - the coloring is yellow as expected - even when using await.
Anybody got any idea? It's starting to drive me crazy!!
It is green when the current instruction pointer is not exactly at the start of the statement. Some common causes:
Common in threaded code, setting a breakpoint in one thread and switching context to another. The other thread will have been interrupted by the debugger at an entirely random location. Often in code that you don't have source code or debugging info for, like String.ToUpper(), the debugger can only show the "closest" source code
Using Debugger + Break All to break into the debugger. Same idea as above, the instruction pointer will be at a random address
Getting an exception in code you don't have debugging info for. The editor shows the last entry in the Call Stack that it does have source code for. You need the call stack window to see where the actual exception was raised. Or the Exception Assistant, its reason for being
Debugging optimized code. The jitter optimizer scrambles the code pretty heavily, making it likely that the debugger can't show the current location accurately
Having out-dated debugging info or editing the code while debugging
Debugging code generated by the x64 jitter, happens when the project's Target Platform setting is AnyCPU. The x64 jitter has a number of chronic bugs that are not getting fixed, generating incorrect debugging info is one of them. Problems that were not addressed until it was completely rewritten, done by the RyuJIT project and first available in .NET version 4.6. Targeting x86 in your EXE project is the workaround.
I understand that this is old post yet I would like to answer the question with my experience.
I have encountered same issue recently in one of my WCF application. After debugging and closely looking service logs and I find out that my code was giving this error because service was hitting max allowed limit for code execution and once the service hit max allowed time limit it was trying to offload the current debugging session.
ERROR IN GREEN STATEMENT: this is the next statement to execute when thread return
So avoiding this issue you can try to look any potential code(Code/Service Timeout or any other code block) which is trying to offload your currently executing code context and try to fix it, furthermore original explanation given by #Hans is still very much relevant for trouble shooting this issue.
Actually, I am also facing this issue. This is because I missed some layout component in landscape mode, So check all the Id's and components and Run, you will not get this error.
I have a multi-threaded application that I'm debugging inside the IDE (Visual Studio 2008, Win7-64, C++).
For "debugging" purposes, I "pretend" that I always have a single processor (the program detects the number of local processors), but the program design establishes a minimum of two threads (e.g., the "main thread" which handles GUI and event traffic, and a second "processing" thread where work is moved off of the "main thread"). (In a "production" build there would be a single main thread, and one-or-more "processing" threads depending on the number of detected processors.)
ISSUE: Breakpoints in the code (within the IDE) sometimes are triggered, and sometimes not. Re-running the program may "catch" on a break point where the previous run it did not "catch" (no source code changes or rebuild is performed to see this change-in-breakpoint-catch-behavior, the program execution path is identical).
(I mostly only care about triggering breakpoints in the non-GUI/non-main-thread, but I assume that should not matter.)
QUESTION: Is there a way to make these break points catch more "reliably"? (What influences whether a break point "catches" or not?)
I'm aware of, and NOT concerned with the following:
Source is out-of-sync with latest linked executable
Build is not "debug" (no debug symbols available)
"Clean build" is needed (debug artifacts out-of-date)
"Step Over/Into" may not work properly when another thread "breaks"
during that first thread's stepping operation
On web searches, there was a mention of possibly setting the compiler setting to "x86" and not "Any Processor" to catch breakpoints, not sure why that might matter ... ?
Finally, yes, of course, all logic "should" be tested in a single-threaded application (e.g., re-factor to ensure deterministic single-threaded execution for unit and regression tests). However, for the current testing, I need to be in the "real" application (think "integration testing" or "systems integration").
Normally breaking is extremely reliable. Here are some things to try:
Hard code a breakpoint with DebugBreak(). This should always be caught, but if this exhibits the same broken behavior, you have narrowed down the problem.
Where you currently have the bp set, add a line to print to screen/file, and set the breakpoint on that line. This is to be certain this line is really even being hit. You may have a strange, unexpected bug that is actually skipping the entire section unexpectedly and this is necessary to be sure.
Try with and without any optimizations. Debugging works best with all optimizations off, but even with deadstripping and inlining features at work, breakpoints are expected to still work. Does this issue occur even with optimizations off?
You say ISO C++, does this mean you've actually switched off all microsoft extensions? I've never compiled this way in visual studio, but if you have, try switching extensions back on and see if that has any effect.
I'm going to agree with VoidStar and other comments. I have worked with VC6, VS2005, VS2008 and VS2010 and I have debugged pretty complex multi-threaded apps with them and breakpoints have always been reliable for me.
With once exception. For projects that use DLLs, sometimes breakpoints that are set in code from a DLL do not work. This is not because VS misses the breakpoint, but instead because the debugger cannot map that line of code to an actual location in the compiled code, probably because the pdb file could not be loaded for some reason. When this happens you see a hollow red circle in the left margin of the breakpoint line instead of the full red ball. Could this be your problem?
I have not figured out why this happens sometimes, but in my experience it only happens for breakpoints in modules that are not the main project being debugged. A workaround that I use is to start the debugger from the DLL, putting the exe in the startup debug configuration for the DLL project. Another trick that sometimes helps is to have all the projects in a single solution, and have them all setup with correct references, so that with one compilation you can rebuild the whole thing.
Good luck, I hope this helps.
I must say I know a lot of things about threads, but theres something that is driving me crazy.
I use to wait for a thread using the Windows API function WaitForSingleObject and it works fine. But, when i am debugging my code, it seems that WaitForSingleObject is very, very, very slow (it hangs a lot). But when I am just running my app without debug, WaitForSingleObject is very, very fast.
Why does this happen? Is it because of Messages that the IDE sends? Or is it because of the compiler?
This is not affecting me a lot. I just think this issue is really annoying.
Edit: I am using Delphi 2010.
I really doubt that WaitForSingleObject is in fact the ONLY thing that gets slower. Rather, it is probable that almost everything gets slower, when you run with debugging on.
I find that far more than Win32 API calls, calls to OutputdebugString slow me down, and anything that the IDE chooses to log in the event view, really, because a big load of these event or output messages, slows the IDE, the debugger, and thus the program that I'm debugging, a lot.
Try turning off the event view checkboxes in the configuration menu and see if EVERYTHING gets faster.
It's in Tools -> Options, as shown by the OP in his image, which I've also added here, for handy access:
Add more ram :) you probably have a not so powerful machine. I had a similar problem but using vs2010. Anyway the principles are the same: Running in debug mode adds an overhead from the checks added by compiler to the code and move overhead from the environment itself that must manages threads, resources and stuff for the case you want to see them.
PS: What makes you think the problem are the Wait* functions ? Have you made a simple application that use Wait* and behaves the same ?