frozen thread.

delphi package - automated exception handling
Post Reply
rossmcm
Posts: 74
Joined: Thu Jun 09, 2005 2:05 am
Contact:

frozen thread.

Post by rossmcm »

I need some help in interpreting a bug report. The application sends emails from a thread using Indy components. The email thread ($d48) stopped sending emails and seems to be snagged in a call to Select. It seems to be waiting for WahReferenceContextByHandle but I don't know what that does. The only reason the main thread is frozen is because I have a button that puts the main thread into a tight loop and the ME antifreeze detection then gives me a bug report. In fact the main thread was executing normally - the only symptom was that emails weren't being sent by the TPooledThreadedEmail thread.

I note that there are 3 other threads running but I'm unsure as to how I tell whether they are contributing to the frozen thread. This is a general problem I have. In the dumps there always seem to be threads waiting for things but I can't work out whether any two threads might be in a deadly embrace.

Many thanks,
Ross

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

exception message : The application seems to be frozen.

main thread ($688):
00166ee8 +00c tad.exe tadmain 6460 +2 TTADMainForm.Button12Click
000a44d2 +062 tad.exe Controls TControl.Click
00087d00 +01c tad.exe StdCtrls TButton.Click
00087df4 +00c tad.exe StdCtrls TButton.CNCommand
000a4341 +111 tad.exe Controls TControl.WndProc
000a6e8a +1d2 tad.exe Controls TWinControl.WndProc
00087c74 +06c tad.exe StdCtrls TButtonControl.WndProc
000a4188 +024 tad.exe Controls TControl.Perform
000a6fb7 +023 tad.exe Controls DoControlMsg
000a74bb +00b tad.exe Controls TWinControl.WMCommand
000a4341 +111 tad.exe Controls TControl.WndProc
000a6e8a +1d2 tad.exe Controls TWinControl.WndProc
000a4341 +111 tad.exe Controls TControl.WndProc
000a6e8a +1d2 tad.exe Controls TWinControl.WndProc
7c90eae0 +010 ntdll.dll KiUserCallbackDispatcher
000a6a8c +02c tad.exe Controls TWinControl.MainWndProc
0008cedc +014 tad.exe Forms StdWndProc
7c90eae0 +010 ntdll.dll KiUserCallbackDispatcher
77d4b8fe +044 user32.dll SendMessageW
77d4e900 +016 user32.dll CallWindowProcA
000a6f62 +0ca tad.exe Controls TWinControl.DefaultHandler
000a4864 +010 tad.exe Controls TControl.WMLButtonUp
000a4341 +111 tad.exe Controls TControl.WndProc
000a6e8a +1d2 tad.exe Controls TWinControl.WndProc
00087c74 +06c tad.exe StdCtrls TButtonControl.WndProc
000a6a8c +02c tad.exe Controls TWinControl.MainWndProc
0008cedc +014 tad.exe Forms StdWndProc
77d496c2 +00a user32.dll DispatchMessageA
000954fb +083 tad.exe Forms TApplication.ProcessMessage
00095532 +00a tad.exe Forms TApplication.HandleMessage
0009573d +081 tad.exe Forms TApplication.Run
00191edc +164 tad.exe tad 76 +27 initialization

thread $bd8: <priority:1>
7c90eb94 +00 ntdll.dll KiFastSystemCallRet
7c90e319 +0a ntdll.dll NtRemoveIoCompletion
0005f3c2 +36 tad.exe madExcept ThreadExceptFrame
>> created by main thread ($688) at:
71a5dbb3 +00 mswsock.dll

thread $870 (TVaCommEventThread):
7c90eb94 +00 ntdll.dll KiFastSystemCallRet
7c90e9be +0a ntdll.dll NtWaitForSingleObject
7c8025d5 +85 kernel32.dll WaitForSingleObjectEx
7c80253d +0d kernel32.dll WaitForSingleObject
000d5f67 +17 tad.exe VaObjects 88 +1 TVaEvent.WaitFor
000d8ed0 +54 tad.exe VaComm 481 +9 TVaCommEventThread.Execute
0005f473 +2b tad.exe madExcept HookedTThreadExecute
000740bc +1c tad.exe Classes ThreadProc
00014150 +28 tad.exe System ThreadWrapper
0005f3c2 +36 tad.exe madExcept ThreadExceptFrame
>> created by main thread ($688) at:
000d8de4 +44 tad.exe VaComm 450 +4 TVaCommEventThread.Create

thread $780 (TVaCommWriteThread): <priority:2>
7c90eb94 +00 ntdll.dll KiFastSystemCallRet
7c90e9a9 +0a ntdll.dll NtWaitForMultipleObjects
7c8094ec +00 kernel32.dll WaitForMultipleObjectsEx
7c809c81 +13 kernel32.dll WaitForMultipleObjects
000d9357 +5b tad.exe VaComm 632 +10 TVaCommWriteThread.Execute
0005f473 +2b tad.exe madExcept HookedTThreadExecute
000740bc +1c tad.exe Classes ThreadProc
00014150 +28 tad.exe System ThreadWrapper
0005f3c2 +36 tad.exe madExcept ThreadExceptFrame
>> created by main thread ($688) at:
000d916a +a6 tad.exe VaComm 567 +8 TVaCommWriteThread.Create

thread $d48 (TPooledThreadedEmail):
7c90eb94 +000 ntdll.dll KiFastSystemCallRet
7c90e9be +00a ntdll.dll NtWaitForSingleObject
71aa150a +06a WS2HELP.dll WahReferenceContextByHandle
71ab2e64 +0a4 WS2_32.dll select
000e1ec4 +024 tad.exe IdStackWindows 816 +2 TIdSocketListWindows.FDSelect
000e1e88 +020 tad.exe IdStackWindows 805 +3 TIdSocketListWindows.SelectRead
000f2266 +006 tad.exe IdSocketHandle 484 +1 TIdSocketHandle.Select
000f204f +027 tad.exe IdSocketHandle 390 +2 CheckIsReadable
000f2107 +06b tad.exe IdSocketHandle 411 +15 TIdSocketHandle.Readable
000f45fa +006 tad.exe IdIOHandlerStack 399 +0 TIdIOHandlerStack.Readable
000f476f +077 tad.exe IdIOHandlerStack 451 +14 TIdIOHandlerStack.ReadFromSource
000f0b35 +14d tad.exe IdIOHandler 1131 +39 TIdIOHandler.ReadLn
000f09d1 +015 tad.exe IdIOHandler 1079 +1 TIdIOHandler.ReadLn
000f0d15 +03d tad.exe IdIOHandler 1180 +5 TIdIOHandler.ReadLnWait
000f921a +04e tad.exe IdTCPConnection 659 +5 TIdTCPConnection.GetInternalResponse
000f8ee5 +00d tad.exe IdTCPConnection 528 +1 TIdTCPConnection.GetResponse
000f8fc1 +041 tad.exe IdTCPConnection 548 +3 TIdTCPConnection.SendCmd
000f90bb +037 tad.exe IdTCPConnection 613 +2 TIdTCPConnection.SendCmd
00108d70 +080 tad.exe IdSMTPBase 213 +17 TIdSMTPBase.SendGreeting
0010a5af +02f tad.exe IdSMTP 399 +3 TIdSMTP.Connect
001787f5 +061 tad.exe tapmail 386 +14 TPooledThreadedEmail.Execute
0005f473 +02b tad.exe madExcept HookedTThreadExecute
000740bc +01c tad.exe Classes ThreadProc
00014150 +028 tad.exe System ThreadWrapper
0005f3c2 +036 tad.exe madExcept ThreadExceptFrame
>> created by main thread ($688) at:
00178537 +01f tad.exe tapmail 281 +1 TPooledThreadedEmail.Create

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
madshi
Site Admin
Posts: 10764
Joined: Sun Mar 21, 2004 5:25 pm

Post by madshi »

It seems to me that this is not really a multi thread deadlock but rather a "simple" frozen thread. Please check out what "IdStackWindows.pas" does in line 816. It seems that this line calls WinSock.select, which does not return. Probably Indy is calling "select" to wait until data is available for reading without specifying a timeout value. For whatever reason "select" never returns, which probably means that unexpectedly no data is being received from the server.

As I said above, I don't believe that this is a deadlock. It rather seems to be a bug in Indy. Or maybe a server which behaves strange and brings Indy to a halt.

I'd suggest to update to the latest Indy version. If that doesn't help, contact Indy support, showing them the callstack of just the frozen thread. Maybe they can help you further. Personally, I'm no Indy expert, so I can't help more here.
rossmcm
Posts: 74
Joined: Thu Jun 09, 2005 2:05 am
Contact:

Post by rossmcm »

Seems as if that is exactly the problem. Currently in discussion with Indy. Many thanks.
Post Reply