Re: [twsocket] AV in TWSocketThrdServer.PutDataInSendBuffer
On Dec 6, 2007, at 04:28, Francois Piette wrote: For some reason, you call PutDataInSendBuffer after it has already been freed. After the object was freed, or the buffer was freed? Keep in mind that I just called WSocketThrdServer.Free, so it was problably destroying the object while it was attempting to send...? If so, how can I prevent this? dZ. -- 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] AV in TWSocketThrdServer.PutDataInSendBuffer
For some reason, you call PutDataInSendBuffer after it has already been freed. After the object was freed, or the buffer was freed? Keep in mind that I just called WSocketThrdServer.Free, so it was problably destroying the object while it was attempting to send...? I think freeing the server object will free all connection objects which each will free the buflist. If so, how can I prevent this? Make sure all connections are closed/aborted before freeing the server object. And as usual, at the application level don't store a reference to a connection object because that reference may become invalid when the object is freed. If you need to store a reference somewhere, then you must code a notification mechanism, probably from the destructor of your client class. -- [EMAIL PROTECTED] Author of ICS (Internet Component Suite, freeware) Author of MidWare (Multi-tier framework, freeware) 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] AV in TWSocketThrdServer.PutDataInSendBuffer
DZ-Jay wrote: On Dec 6, 2007, at 04:28, Francois Piette wrote: For some reason, you call PutDataInSendBuffer after it has already been freed. After the object was freed, or the buffer was freed? The buffer is freed in the destructor of TCustomWSocket. Keep in mind that I just called WSocketThrdServer.Free, so it was problably destroying the object while it was attempting to send...? If so, how can I prevent this? I think it helps to disconnect all, then destroy the server object after all clients have been actually disconnected. -- Arno Garrels -- 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] AV in TWSocketThrdServer.PutDataInSendBuffer
On Dec 6, 2007, at 05:39, Arno Garrels wrote: I think it helps to disconnect all, then destroy the server object after all clients have been actually disconnected. I'll look into this, but as far as I recall (I have no access to the source code right now), the TWSocketThrdServer destructor calls DisconnectAll which does this. And (as I seem to recall also), it uses WaitForMultipleObjects() until the clients notify that they have finished and frees them. What I'm saying is that I was under the impression that the server class was handling the disconnection of all clients when destroyed. If this is not true, then I can build it into my application, no problem; but if it is true, then that means there may be something wrong in the code. I'll see what I can find when I get to the office later on. 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] AV in TWSocketThrdServer.PutDataInSendBuffer
DZ-Jay wrote: On Dec 6, 2007, at 05:39, Arno Garrels wrote: I think it helps to disconnect all, then destroy the server object after all clients have been actually disconnected. I'll look into this, but as far as I recall (I have no access to the source code right now), the TWSocketThrdServer destructor calls DisconnectAll which does this. Not in my sources. It posts a message to tell the threads that they shall terminate. When a thread terminates clients are just ThreadDetached. And (as I seem to recall also), it uses WaitForMultipleObjects() until the clients notify that they have finished and frees them. It waits until all worker threads are finished thus all client's HWND is 0, that may cause the problem. What I'm saying is that I was under the impression that the server class was handling the disconnection of all clients when destroyed. If this is not true, then I can build it into my application, no problem; but if it is true, then that means there may be something wrong in the code. The problem is that TriggerSessionClosed won't be called when you disconnect a client from server's destructor or from a destructor of its owner since csDestroying would be in component states (see InternalClose). I guess it's worth a trial to simply ThreadAttach all clients in the destructor after all threads terminated. .. until FThreadList.Count = 0; ==for I := ClientCount -1 downto 0 do ==Client[I].ThreadAttach; -- Arno Garrels I'll see what I can find when I get to the office later on. 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] AV in TWSocketThrdServer.PutDataInSendBuffer
[EMAIL PROTECTED] wrote: Quote from Arno: csDestroying is already in the states when you call DisconnectAll() from the destructor of the server's owner component. If you created the server with a nil owner, no problemo. - Then, as you say, there's no problemo, because that's exactly what I do. :) So, to make sure I understand: If I call DisconnectAll() before destroying the server component, I still need to wait and process messages to make sure all clients are disconnected *before* calling the server's destructor, or else it may never fire OnSessionClose() on them once it starts destroying, right? Yes, that should work. Arno -dZ. -- 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
[twsocket] AV in TWSocketThrdServer.PutDataInSendBuffer
Hello:
I was testing my application and and noticed in
the log that when I tried to destroy the
TWSocketThrdServer while it had opened connections, I
got a few (seemingly) random AVs which I traced to
the following lines in PutDataInSendBuffer method:
procedure TCustomWSocket.PutDataInSendBuffer(Data :
Pointer; Len : Integer);
var
oBuffer : TBuffer;
cWritten : Integer;
bMore : Boolean;
begin
if (Len = 0) or (Data = nil) then
exit;
{$IFDEF COMPILER2_UP}
EnterCriticalSection(GSendBufCritSect);
try
{$ENDIF}
{ THE FOLLOWING LINE }
if FBufList.Count = 0 then begin
oBuffer := TBuffer.Create(FBufSize);
FBufList.Add(oBuffer);
end
else
oBuffer := FBufList.Last;
Inc(FBufferedByteCount, Len);
bMore := TRUE;
while bMore do begin
cWritten := oBuffer.Write(Data, Len);
if cWritten = Len then
bMore := FALSE
else begin
Len := Len - cWritten;
Data := PChar(Data) + cWritten;
if Len 0 then
bMore := FALSE
else begin
oBuffer := TBuffer.Create(FBufSize);
FBufList.Add(oBuffer);
end;
end;
end;
bAllSent := FALSE;
{$IFDEF COMPILER2_UP}
finally
LeaveCriticalSection(GSendBufCritSect);
end;
{$ENDIF}
end;
The full error is [EAccessViolation] Access
violation at address 00469094 in module
'SmailQ_con.exe'. Read of address 0008
Its hard for me to reproduce exactly, but has
anybody any idea what could be causing this?
-dZ.
--
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
