Re: [twsocket] bug in TCustomWSocket? - 100% cpu; continues calls to OnDataAvailable while no data was received
I've removed the parsing and processing of data from the OnDataAvailable. The event handler now basically contains ReceiveStr() and PostMessage(). I'm still having the same problem though :( It seems that this problem is not triggered by doing something wrong in the OnDataAvailable event handler, but somewhere else. I'm starting to think it's something in the sending of data since that keeps coming back in the callstack (see attached callstack). Hoping someone can give me a hint. Merijn |--| |7C810E31|kernel32.dll| | |WriteFile | | |7C90D590|ntdll.dll | | |NtClose | | |7C809BA5|kernel32.dll| | |CloseHandle | | |7C809B67|kernel32.dll| | |CloseHandle | | |006BF6B2|AviaVox.exe |ServerTimedSocket.pas|TServerTimedSocket |_Log|301[17] | |71AA150A|WS2HELP.dll | | |WahReferenceContextByHandle | | |71AB4376|WS2_32.dll | | |WSARecv | | |71AB437D|WS2_32.dll | | |WSARecv | | |71AB4318|WS2_32.dll | | |WSARecv | | |71AD2E9E|wsock32.dll | | |recv| | |005C569F|AviaVox.exe |WSocket.pas | |WSocket_Synchronized_recv |2277[3] | |005C6B00|AviaVox.exe |WSocket.pas |TCustomWSocket |DoRecv |3825[0] | |005CC772|AviaVox.exe |WSocket.pas |TCustomSocksWSocket |DoRecv |6759[2] | |0055F9C4|AviaVox.exe |PostPone.pas |TPostPone |PostPone|80[1]| |006BF84E|AviaVox.exe |ServerTimedSocket.pas|TServerTimedSocket |OnDataAvailable |333[20] | |71AB44E5|WS2_32.dll | | |WSAIoctl| | |71AB4489|WS2_32.dll | | |WSAIoctl| | |71AB4536|WS2_32.dll | | |ioctlsocket | | |005C5398|AviaVox.exe |WSocket.pas | |WSocket_Synchronized_ioctlsocket|2136[3] | |005C5374|AviaVox.exe |WSocket.pas | |WSocket_Synchronized_ioctlsocket|2133[0] | |005C7229|AviaVox.exe |WSocket.pas |TCustomWSocket |ASyncReceive|4226[28] | |7C80A424|kernel32.dll| | |CompareStringW | | |7C80A37E|kernel32.dll| | |CompareStringW | | |7C90D8ED|ntdll.dll | | |NtDeviceIoControlFile | | |71AB42F5|WS2_32.dll | | |send| | |71AB42FC|WS2_32.dll | | |send| | |005C52E7|AviaVox.exe |WSocket.pas | |WSocket_Synchronized_send |2098[3] | |005C2808|AviaVox.exe |WSockBuf.pas |TBuffer |Peek|212[0] | |005C6D8A|AviaVox.exe |WSocket.pas |TCustomWSocket |TryToSend |4006[16] | |005C6F07|AviaVox.exe |WSocket.pas |TCustomWSocket |TryToSend |4070[80] | |7E41CBB3|USER32.dll | | |PostMessageA| | |7E41CB69|USER32.dll | | |PostMessageA| | |005C710A|AviaVox.exe |WSocket.pas |TCustomWSocket |Send|4164[31] | |005C715A|AviaVox.exe |WSocket.pas |TCustomWSocket |SendStr |4177[2] | |006BFA70|AviaVox.exe |ServerTimedSocket.pas|TServerTimedSocket
Re: [twsocket] bug in TCustomWSocket? - 100% cpu; continues calls to OnDataAvailable while no data was received
Sorry for the late reply, we've had an expo this week which needed some (a lot) of attention. I didn't find any calls to ProcessMessages(). This socket runs in it's own thread, so a call to ProcessMessages() would have been out of place. I did find something else though. Even though the server socket had it's MultiThreaded property set to true, the client socket it spawns did not have this property set to true explicitly. Therefor ICS was calling ProcessMessages() itself now and then. Maybe it would be a good idea to let TCustomWSocketServer set Multithreaded of newly created clients to the same value it has itself? WSocketS.pas around line 360. Anyway, back to my problem, because it's still here :| All sockets have now their MultiThreaded property set to true. I removed the wsoNoReceiveLoop again, because it didn't seem to have to do anything with the problem. I've added some logging when the problem occurs, so I have some new information. The OnDataAvailable event is never triggered from within itself. So it seems not to be caused by calling a messagepump in the event, which triggers the event again! If in the loop, in each event there is no data to receive. If in the loop, in each event, error = 0 If in the loop, in each event I note LastError before, and after I call ReceiveStr(). I do this because TCustomWSocket.ASyncReceive, which triggers the event, looks at FLastError to decide it should call the event again. In both cases I had the extended logging, LastError was set to a non-zero value. In the first case it was 10054, and the second case it was 10034. LastError was the same before and after the call to ReceiveStr(). Besides the extended logging, I built in a mechanism which automatically dumps a call stack of the thread the socket runs in, 60 seconds after I get stuck in the 'loop'. Of course this call stack is just a snapshot somewhere in the loop, but since I got the same call stack a couple of times now, I'm pretty sure this is how the OnDataAvailable event is triggered. The strange thing is, that there always seems to be a strange 'jump' in the call stack which I can't explain (or probably which I don't understand): It goes from Do_FD_READ to AsyncReceive (normal), but before AsyncReceive is actually run, it jumps to TriggerDataSent (?). After that some other strange things in the call stack. See the call stack here, the calls to CheckForPendingMessages are calls to methods which call the messagepumps for different controls, amongst which TCustomWSocket.ProcessMessages(). I really hope someone can give me some more pointers in the right direction! callstack: |7C90E9FD|ntdll.dll | | |NtWriteFile | | |7C810E10|kernel32.dll| | |WriteFile | | |006C268B|AviaVox.exe |ServerTimedSocket.pas |TServerTimedSocket |_Log|291[16] | |006C2528|AviaVox.exe |ServerTimedSocket.pas |TServerTimedSocket |_Log|275[0] | |006C27DB|AviaVox.exe |ServerTimedSocket.pas |TServerTimedSocket |OnDataAvailable |305[8] | |005CBFA0|AviaVox.exe |WSocket.pas |TCustomWSocket |TriggerDataAvailable|5970[24] | |005CBF80|AviaVox.exe |WSocket.pas |TCustomWSocket |TriggerDataAvailable|5946[0] | |005CDA0B|AviaVox.exe |WSocket.pas |TCustomSocksWSocket|TriggerDataAvailable|6504[2] | |005CD9E0|AviaVox.exe |WSocket.pas |TCustomSocksWSocket|TriggerDataAvailable|6502[0] | |005CE90C|AviaVox.exe |WSocket.pas |TCustomLineWSocket |TriggerDataAvailable|7065[7] | |005C8C58|AviaVox.exe |WSocket.pas |TCustomWSocket |ASyncReceive|4204[6] | |005C6DB3|AviaVox.exe |WSocket.pas | |WSocket_Synchronized_ioctlsocket|2136[3] | |005C6D8C|AviaVox.exe |WSocket.pas | |WSocket_Synchronized_ioctlsocket|2133[0] | |005C8CDD|AviaVox.exe |WSocket.pas |TCustomWSocket |ASyncReceive|4226[28] | |71AB42F5|WS2_32.dll | | |send| | |71AB42FC|WS2_32.dll | | |send| | |005C6CF7|AviaVox.exe |WSocket.pas | |WSocket_Synchronized_send |2098[3] | |005CBEDC|AviaVox.exe |WSocket.pas |TCustomWSocket |TriggerSendData |5907[0] | |005C87A9|AviaVox.exe |WSocket.pas |TCustomWSocket
Re: [twsocket] bug in TCustomWSocket? - 100% cpu; continues calls to OnDataAvailable while no data was received
I just noticed the layout of the call stack got kind of messed up, so I've attached as a text file. Merijn Bosma wrote: Sorry for the late reply, we've had an expo this week which needed some (a lot) of attention. I didn't find any calls to ProcessMessages(). This socket runs in it's own thread, so a call to ProcessMessages() would have been out of place. I did find something else though. Even though the server socket had it's MultiThreaded property set to true, the client socket it spawns did not have this property set to true explicitly. Therefor ICS was calling ProcessMessages() itself now and then. Maybe it would be a good idea to let TCustomWSocketServer set Multithreaded of newly created clients to the same value it has itself? WSocketS.pas around line 360. Anyway, back to my problem, because it's still here :| All sockets have now their MultiThreaded property set to true. I removed the wsoNoReceiveLoop again, because it didn't seem to have to do anything with the problem. I've added some logging when the problem occurs, so I have some new information. The OnDataAvailable event is never triggered from within itself. So it seems not to be caused by calling a messagepump in the event, which triggers the event again! If in the loop, in each event there is no data to receive. If in the loop, in each event, error = 0 If in the loop, in each event I note LastError before, and after I call ReceiveStr(). I do this because TCustomWSocket.ASyncReceive, which triggers the event, looks at FLastError to decide it should call the event again. In both cases I had the extended logging, LastError was set to a non-zero value. In the first case it was 10054, and the second case it was 10034. LastError was the same before and after the call to ReceiveStr(). Besides the extended logging, I built in a mechanism which automatically dumps a call stack of the thread the socket runs in, 60 seconds after I get stuck in the 'loop'. Of course this call stack is just a snapshot somewhere in the loop, but since I got the same call stack a couple of times now, I'm pretty sure this is how the OnDataAvailable event is triggered. The strange thing is, that there always seems to be a strange 'jump' in the call stack which I can't explain (or probably which I don't understand): It goes from Do_FD_READ to AsyncReceive (normal), but before AsyncReceive is actually run, it jumps to TriggerDataSent (?). After that some other strange things in the call stack. See the call stack here, the calls to CheckForPendingMessages are calls to methods which call the messagepumps for different controls, amongst which TCustomWSocket.ProcessMessages(). I really hope someone can give me some more pointers in the right direction! callstack: |7C90E9FD|ntdll.dll | | |NtWriteFile | | |7C810E10|kernel32.dll| | |WriteFile | | |006C268B|AviaVox.exe |ServerTimedSocket.pas |TServerTimedSocket |_Log|291[16] | |006C2528|AviaVox.exe |ServerTimedSocket.pas |TServerTimedSocket |_Log|275[0] | |006C27DB|AviaVox.exe |ServerTimedSocket.pas |TServerTimedSocket |OnDataAvailable |305[8] | |005CBFA0|AviaVox.exe |WSocket.pas |TCustomWSocket |TriggerDataAvailable|5970[24] | |005CBF80|AviaVox.exe |WSocket.pas |TCustomWSocket |TriggerDataAvailable|5946[0] | |005CDA0B|AviaVox.exe |WSocket.pas |TCustomSocksWSocket|TriggerDataAvailable|6504[2] | |005CD9E0|AviaVox.exe |WSocket.pas |TCustomSocksWSocket|TriggerDataAvailable|6502[0] | |005CE90C|AviaVox.exe |WSocket.pas |TCustomLineWSocket |TriggerDataAvailable|7065[7] | |005C8C58|AviaVox.exe |WSocket.pas |TCustomWSocket |ASyncReceive|4204[6] | |005C6DB3|AviaVox.exe |WSocket.pas | |WSocket_Synchronized_ioctlsocket|2136[3] | |005C6D8C|AviaVox.exe |WSocket.pas | |WSocket_Synchronized_ioctlsocket|2133[0] | |005C8CDD|AviaVox.exe |WSocket.pas |TCustomWSocket |ASyncReceive|4226[28] | |71AB42F5|WS2_32.dll | | |send| | |71AB42FC|WS2_32.dll | | |send| | |005C6CF7|AviaVox.exe |WSocket.pas | |WSocket_Synchronized_send |2098[3] | |005CBEDC|AviaVox.exe |WSocket.pas
Re: [twsocket] bug in TCustomWSocket? - 100% cpu; continues calls to OnDataAvailable while no data was received
On Apr 11, 2008, at 03:39, Merijn Bosma wrote: In case I am, could that explain this behavior? I'm not calling the message pump when I'm receiving no data, so shouldn't that break the loop if it was there? You also may want to trace deep into all the procedures you call from the event handler to see if any of them ultimately call the message pump. dZ. -- DZ-Jay [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] bug in TCustomWSocket? - 100% cpu; continues calls to OnDataAvailable while no data was received
Merijn Bosma wrote: Hello, Yesterday evening we've found out that this problem still occurs, even with wsoNoReceiveLoop set. The symptoms are the same: - OnDataAvailable event is triggered continuously (close to 14000 times per second) - ReceiveStr() is called every time, returning no data - Error is always 0 in the events - The event keeps being triggered until we shut down the application. This is not a high speed stream, we sent only control data, so approx up to 100 bytes every few seconds. I'm I doing something stupid or is there something else going wrong here? If it's not me, is there any way for to determine whether this is a problem with ICS, or with the Windows call stack itself? Francois PIETTE wrote: One possible explanation were that anytime OnDataAvailable returns, just a few _new_ bytes are available in winsock buffer. Could be possible due to the background thread winsock creates internally with non-blocking sockets, though I'm not aware of how winsock works under the hood. When in this situation, we got a few hundred calls a second, for an unlimited time, where normally it's one every few seconds. I agree with you, it could be a possible cause, but very unlikely. Do you receive data each time you call ReceiveStr ? If yes, then probably you have a fast network, and your application becomes CPU bound. That's the thing, I don't receive any data. At least not using ReceiveStr() btw: Since you don't use line mode, I strongly suggest you avoid ReceiveStr and instead use Receive with a fixed buffer. Calling ReceiveStr will force the runtime to create new string and copy data into it, and probably youthen copy data elsewhere for processing. All this is very CPU intensive. The best way to design a high performance application is to use a fixed buffer (which may be dynamically allocated but not each time you receive data). And use the buffer as close as possible of the processing each time you copy data, each time you consume CPU and memory for nothing. -- [EMAIL PROTECTED] The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] bug in TCustomWSocket? - 100% cpu; continues calls to OnDataAvailable while no data was received
Hi, - OnDataAvailable event is triggered continuously (close to 14000 times per second) Do you call the message pump from OnDataAvailable, directly or indirectly (i.e. Application.ProcessMessages, any Showmessage() or a VCL-dialog)? -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html Merijn Bosma wrote: Merijn Bosma wrote: Hello, Yesterday evening we've found out that this problem still occurs, even with wsoNoReceiveLoop set. The symptoms are the same: - OnDataAvailable event is triggered continuously (close to 14000 times per second) - ReceiveStr() is called every time, returning no data - Error is always 0 in the events - The event keeps being triggered until we shut down the application. This is not a high speed stream, we sent only control data, so approx up to 100 bytes every few seconds. I'm I doing something stupid or is there something else going wrong here? If it's not me, is there any way for to determine whether this is a problem with ICS, or with the Windows call stack itself? Francois PIETTE wrote: One possible explanation were that anytime OnDataAvailable returns, just a few _new_ bytes are available in winsock buffer. Could be possible due to the background thread winsock creates internally with non-blocking sockets, though I'm not aware of how winsock works under the hood. When in this situation, we got a few hundred calls a second, for an unlimited time, where normally it's one every few seconds. I agree with you, it could be a possible cause, but very unlikely. Do you receive data each time you call ReceiveStr ? If yes, then probably you have a fast network, and your application becomes CPU bound. That's the thing, I don't receive any data. At least not using ReceiveStr() btw: Since you don't use line mode, I strongly suggest you avoid ReceiveStr and instead use Receive with a fixed buffer. Calling ReceiveStr will force the runtime to create new string and copy data into it, and probably youthen copy data elsewhere for processing. All this is very CPU intensive. The best way to design a high performance application is to use a fixed buffer (which may be dynamically allocated but not each time you receive data). And use the buffer as close as possible of the processing each time you copy data, each time you consume CPU and memory for nothing. -- [EMAIL PROTECTED] The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] bug in TCustomWSocket? - 100% cpu; continues calls to OnDataAvailable while no data was received
Arno Garrels wrote: Hi, - OnDataAvailable event is triggered continuously (close to 14000 times per second) Do you call the message pump from OnDataAvailable, directly or indirectly (i.e. Application.ProcessMessages, any Showmessage() or a VCL-dialog)? I'm digging through code right now just to be sure. In case I am, could that explain this behavior? I'm not calling the message pump when I'm receiving no data, so shouldn't that break the loop if it was there? -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] bug in TCustomWSocket? - 100% cpu; continues calls to OnDataAvailable while no data was received
Merijn Bosma wrote: Arno Garrels wrote: Hi, - OnDataAvailable event is triggered continuously (close to 14000 times per second) Do you call the message pump from OnDataAvailable, directly or indirectly (i.e. Application.ProcessMessages, any Showmessage() or a VCL-dialog)? I'm digging through code right now just to be sure. In case I am, could that explain this behavior? I think so. I'm not calling the message pump when I'm receiving no data, so shouldn't that break the loop if it was there? The event handler may be reentered, so don't call the message pump from there. If you want i.e. display a dialog you could post a custom message and from its message handler pop up the dialog. -- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
