I've found some good questions and with good answers for naming threads in Delphi.
Like this one Named threads in Delphi - what is that for?.
But how, while debugging, I get to see the name of the thread?
And also, even with that, I cannot see the thread name in utilities like Process Explorer right?
When the execution is paused (because you trigger the pause by clicking the "pause" icon or selecting menu Run, Program Pause; or because the breakpoint is hit), the thread names are visible in the Threads window (View, Debug Windows, Threads; or Ctrl-Alt-T).
No, Process Explorer cannot show thread names.
Related
my understanding about debugging process and debuggers is that when a breakpoint gets hit, all other threads gets frozen. However one of my colleague said that this option is configurable meaning that somewhere in Visual Studio options you can configure that other threads (where there is no breakpoint) continue to work as normal although the thread with breakpoint get frozen. I couldn't find any such settings in visual studio plus my colleague does not remember where he saw that setting although he seem pretty confident that this option exists.
Can someone confirm if its even possible to have other threads running while one thread gets frozen due to breakpoint? Also if there is such a setting, please let me know where to find it.
The debugger always freezes all threads when a breakpoint hits. You have however do have control over what happens to threads when you press F5 to continue execution. You can use the Freeze toolbar button available in the Debug + Windows + Threads debugger window to prevent a thread from continuing when you press F5. Use the Thaw button to re-enable it.
I'm not familiar with VS, but I know gdb support non-stop mode since version 7.10, so I think it is possible to do like this with VS.
Here is the summary: "For some multi-threaded targets, GDB supports an optional mode of operation in which you can examine stopped program threads in the debugger while other threads continue to execute freely. This minimizes intrusion when debugging live systems, such as programs where some threads have real-time constraints or must continue to respond to external events. This is referred to as non-stop mode."
You can search 'non-stop gdb' for more details.
I don't know if this is possible but frankly if it is, it shouldn't be. Yes it is theoretically possible to break one thread while the others keep running, but keep in mind that with this there is the potential that one of the running threads will try to interact with the frozen thread. this causes all kinds of problems with your current frozen thread. I suspect the debugger was designed with this in mind, so there isn't a setting that allows this. If someone else knows differently please let me know because i find myself curious as well
When I step over (F10) in the debugger, I am staying on the thread I am currently in.
Therefore, when I step over a line of code, and the process crash in an over thread, I am not able to see in which thread it went.
As I don't know in which thread the crash is happening, I can not simply click on it in the thread window.
Do you know how to switch to "guilty" thread ?
Thanks
You can go into Debug >> Windows >> threads to see all your threads. You can also right lick on thread and select 'switch thread'.
Is it possible to use TrackPopupMenu from a secondary thread? I'm trying to use it with TPM_NONOTIFY and TPM_RETURNCMD flags.
In our code, the call to TrackPopupMenu returns immediately without displaying the menu, indicating that the user cancelled the menu.
The same code, when called from the main/gui thread works fine.
You need to run this from the same thread that owns the window to which the menu is attached.
The threading rule in Windows is that windows have affinity to the thread that creates the window. Since TrackPopupMenu receives a window handle, you can assume that it must be called from that window's thread.
In practice on Windows (and all GUI frameworks that I have ever come across), everything related to the GUI should happen in the main thread.
What happens if I breakpoint a multi thread application.
does it stop all the threads, just the one that is break pointed or does the whole program just crash ?
If it is possible would I want to stop just one thread or would this mess up my application ?
If I cannot break point a multi tread application what are the debug techniques available to me ?
JAVA: As far as personal experience goes, you can debug multi-threaded applications by stopping all threads or individual threads. It would most likely depend on what IDE you are using, and what application you are connecting to, but for me its:
Eclipse connecting in debug mode to a Tomcat server running in jpda
Place a breakpoint in the code, go to Eclipse's debug perspective (sometimes it pauses but doesn't switch perspective)
In the breakpoints window, you will see a list of breakpoints. Each one you can right-click and set properties on... if you want to stop all threads on one breakpoint, hit the Suspend VM radio button. If you only want to stop a single thread, click suspend thread.
I'm not sure you're able at this point to select which thread you want to pause if using the single thread stop option. In Suspend VM, you can look at the Debug pane and see your thread... scroll down and you can jump between the threads (Daemon thread 10 vs Daemon thread 9, something like that)
It stops all threads.
It is not normally possible to just stop one thread. For more information on debugging threads with GDB see this part of the manual.
Since you didn't tag your question with a specific language/platform, I'll give a Java-related answer.
In most IDEs you can set properties on your breakpoints, specifically conditional properties. So, if you know the name of your thread, you can do something like this:
"ThreadName".equals(Thread.currentThread().getName())
...and all other threads utilising the same class (where you set the breakpoint) will carry on unhindered.
When I am debugging within Visual Studio, for some reason when debugging a certain thread, Visual Studio will just jump around to different threads.
How do I change to behavior so it sits on the same thread?
When you say, "when debugging a certain thread, visual studio will just jump around randomly to different threads", do you mean that as you step through code on a particular thread you may hit a breakpoint on a different thread?
If so, you can use the Thread window to 'freeze' threads other than the one you're interested in debugging:
From http://msdn.microsoft.com/en-us/library/w15yf86f.aspx:
From the Threads window, you can set
the active thread. In addition, you
can freeze or thaw the execution of
each individual thread. Freezing
prevents the execution of a thread.
Thawing enables it to continue. Two
vertical blue bars identify a frozen
thread.
Support for this may depend on the version of Visual Studio you have (for example, I don't think the Express versions support the Thread window).
All the answers here talk about freezing the threads, but it gets cumbersome when there're lots of them, and you don't know which one to freeze. I found an easier trick.
When a breakpoint is hit by a thread i, and say j, k, etc. are going to hit the same in some time, then disable the breakpoint temporarily and start debugging thread i. I see that the debugger doesn't jump on to the other threads since for those threads there's no breakpoint to break into. Enable the breakpoint when you're done debugging.
It is the default because running the program in the debugger shouldn't change the results of the program, I assume.
When the program is running "live", it is constantly switching between threads, so if the debugger didn't do the same, the program would be behaving differently.
In any case, the only way I know of to prevent it is to open the Threads window, right click on all other threads than the current one, and select freeze. (Remember to thaw them again afterwards)
Generally, I freeze the other threads by right-click in the threads panel. I don't know if this is sane or not though.