I have a bug I am chasing (I think its a deadlock). When I run the code it hangs without the debugger flagging an error, so after a while I try pressing the pause (break all) button. The debugger then reports "The process appears to be deadlocked...". I then can see that all the threads are held up at lines saying EnterCriticalSection except for one which is already inside a critical section. When I look at the thread that is inside the C.S. with the debugger I see a green arrow, accompanied by a tiny blue circle pointing at a line with GetWindowText... as below:
// stuff A
{
GetWindowText(editwin[a].child_window_handle,existing_text,MAX_TEXT_SIZE-1);
}
// stuff B
If I hover the mouse over the green arrow I see the text "this is the next statement to execute when this thread returns from the current function". Now this has stumped me because I don't know if it means that it is stuck inside "stuff A" and is waiting to come back or its stuck inside GetWindowText and has somehow got stuck inside that. The arguments to GetWindowText all look sensible to me. If I click on "step into" I get the message "Unable to step. The process has been soft broken".
EDIT: stuff A is in fact the statement:
if (buf_ptr != NULL)
In hardware development, the debugging process typically looks for hardware components that are not installed or configured correctly. For example, an engineer might run a JTAG connection test to debug connections on an integrated circuit.
Debugging tools (called debuggers) are used to identify coding errors at various development stages. They are used to reproduce the conditions in which error has occurred, then examine the program state at that time and locate the cause.
Usually a green arrow beside a line of code means "this is the next line that would be executed, if not for the fact we're stuck somewhere in a deeper stack frame." However, VS makes it impossible to say for sure based on the info provided so far...
[EDIT - of course, deep knowledge of Win32 can provide a very good guess - see the answer by "mos" for a likely explanation based on the GetWindowText() API's known pitfalls]
As mentioned, what Visual Studio shows you is sometimes misleading. To get a closer view of exactly what is happening you need to turn off some non-helpful "features" that VS enables by default. In Tools -> Options -> Debugging -> General, make sure:
This should allow you to:
1) break on / step over / etc the exact instruction that's causing the deadlock
2) see the full stack trace up to that point, regardless of module(s)
3) see source code whenever available, assuming your symbol & source servers are configured correctly
Your problem is that GetWindowText actually sends a message to the other window and waits for it to return. If that window is owned by another thread that is waiting for a critical section, GetWindowText will wait forever.
You're stuck inside GetWindowText, and have created a deadlock.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With