Board index » delphi » AV with TIdTCPServer.Active := False ?

AV with TIdTCPServer.Active := False ?

When ever I try to close clients with Active := False or
Connection.DisconnectSocket/Disconnect; I get a AV. The IDE directs me to
this line of code --->

IdSocketHandel.pas

function TIdSocketHandle.Recv(var ABuf; ALen, AFlags: Integer): Integer;
begin
--->  result := GStack.WSRecv(Handle, ABuf, ALen, AFlags);
end;

If the client closes the connection the normal exception is raized.

anyone have any ideas? This only started with Indy v9.0

Cheers
Steve

 

Re:AV with TIdTCPServer.Active := False ?


In case you call Active := false when you have active connection whcih reads
something at the same time this is normal. This is happening becouse the
DisconnectSocket frees the Binding and Handle is not valid any more. The
exception is catched in the server code and is used to inform the rest of
the thread code that the connection has been closed.

Doychin Bondzhev - Team Indy

Quote
"Steve" <s...@icon.co.za> wrote in message news:3b900aca_1@dnews...
> When ever I try to close clients with Active := False or
> Connection.DisconnectSocket/Disconnect; I get a AV. The IDE directs me to
> this line of code --->

> IdSocketHandel.pas

> function TIdSocketHandle.Recv(var ABuf; ALen, AFlags: Integer): Integer;
> begin
> --->  result := GStack.WSRecv(Handle, ABuf, ALen, AFlags);
> end;

> If the client closes the connection the normal exception is raized.

> anyone have any ideas? This only started with Indy v9.0

> Cheers
> Steve

Re:AV with TIdTCPServer.Active := False ?


"Doychin Bondzhev - Team Indy" <doyc...@dsoft-bg.com> wrote in message
news:3b907cf3_2@dnews...

Quote
> In case you call Active := false when you have active connection whcih
reads
> something at the same time this is normal. This is happening becouse the
> DisconnectSocket frees the Binding and Handle is not valid any more. The
> exception is catched in the server code and is used to inform the rest of
> the thread code that the connection has been closed.

Hi Doychin. Thank you for your response :)

I also said that when I do a
TIdPeerThread(Peer.Items[0]).Connection.DisconnectSocket; I get the access
violation as well. ? I can understand Active := False giving me a AV but not
disconnecting an actual client manually ?

Cheers Steve
PS there is only 1 client connected to the server so Peer 0 is valid.

Re:AV with TIdTCPServer.Active := False ?


Raising a planned AV is not a good thing, in my opinion,  as you never know
if it will be handled correctly or not.  As you known, an unhandled AV in a
thread will cause all sorts of bad things (usually by terminating your app
or worse).  I suspect this may be the root cause of the thread timeout
errors we mentioned before when shutting down a server that has active
clients.

Would it not make more sense to do the following when setting active :=
false?

1) Prevent the listener socket from accepting any more connections.
2) Shutdown active connections gracefully.
3) When all active connections have been terminated, actually set the
property to false or raise an event letting the application know the server
has been stopped?

Charles

"Doychin Bondzhev - Team Indy" <doyc...@dsoft-bg.com> wrote in message
news:3b907cf3_2@dnews...

Quote
> In case you call Active := false when you have active connection whcih
reads
> something at the same time this is normal. This is happening becouse the
> DisconnectSocket frees the Binding and Handle is not valid any more. The
> exception is catched in the server code and is used to inform the rest of
> the thread code that the connection has been closed.

> Doychin Bondzhev - Team Indy

> "Steve" <s...@icon.co.za> wrote in message news:3b900aca_1@dnews...
> > When ever I try to close clients with Active := False or
> > Connection.DisconnectSocket/Disconnect; I get a AV. The IDE directs me
to
> > this line of code --->

> > IdSocketHandel.pas

> > function TIdSocketHandle.Recv(var ABuf; ALen, AFlags: Integer): Integer;
> > begin
> > --->  result := GStack.WSRecv(Handle, ABuf, ALen, AFlags);
> > end;

> > If the client closes the connection the normal exception is raized.

> > anyone have any ideas? This only started with Indy v9.0

> > Cheers
> > Steve

Re:AV with TIdTCPServer.Active := False ?


Quote
> 1) Prevent the listener socket from accepting any more connections.

Actually the problem is with listening thread. It is with already active
connections which has to be closed and if they are doing something with
sockets the only way to top them is to close all sockets. Closing all sockes
couses all these AV's which are handlend in the Execute method of
TIdPeeThread and then all threads are terminated.

The reason of timeout problems is mostly bad written OnExecute code.

Quote
> 2) Shutdown active connections gracefully.

You can't shutdown them gracefully becouse you have to force the close
operation and the only way is DisconnectSocket. Becouse it frees the Binding
property this couse the AV' sibn Recv or Send methods.

I can only advice you to update your indy sources and try with all new
changes we did in the last few days.

Doychin Bondzhev  - Team Indy

Re:AV with TIdTCPServer.Active := False ?


Hmmm.  From what you've written the problem is that if you have an AV in the
kernel or in Winsock itself,  you  may not be able to catch it and recover
gracefully.

There is no reason that you can't stop accepting connections on a listening
socket.  Just refuse the connection instead of accepting.  Then, you can
safely shutdown the other connections.

I will try the latest revisions to see if they make a difference.

Charles

"Doychin Bondzhev - Team Indy" <doyc...@dsoft-bg.com> wrote in message
news:3b90fa3a_2@dnews...

Quote
> > 1) Prevent the listener socket from accepting any more connections.

> Actually the problem is with listening thread. It is with already active
> connections which has to be closed and if they are doing something with
> sockets the only way to top them is to close all sockets. Closing all
sockes
> couses all these AV's which are handlend in the Execute method of
> TIdPeeThread and then all threads are terminated.

> The reason of timeout problems is mostly bad written OnExecute code.

> > 2) Shutdown active connections gracefully.

> You can't shutdown them gracefully becouse you have to force the close
> operation and the only way is DisconnectSocket. Becouse it frees the
Binding
> property this couse the AV' sibn Recv or Send methods.

> I can only advice you to update your indy sources and try with all new
> changes we did in the last few days.

> Doychin Bondzhev  - Team Indy

Re:AV with TIdTCPServer.Active := False ?


Exceptions does not accoure in the Kernelo or winsock. They occure becouse
of freeing the TIdIOHandlerSocket.Binding property.

Quote
"Charles Stack" <char...@codycomp.com> wrote in message

news:3b90fde0$1_1@dnews...
Quote
> Hmmm.  From what you've written the problem is that if you have an AV in
the
> kernel or in Winsock itself,  you  may not be able to catch it and recover
> gracefully.

> There is no reason that you can't stop accepting connections on a
listening
> socket.  Just refuse the connection instead of accepting.  Then, you can
> safely shutdown the other connections.

> I will try the latest revisions to see if they make a difference.

> Charles

> "Doychin Bondzhev - Team Indy" <doyc...@dsoft-bg.com> wrote in message
> news:3b90fa3a_2@dnews...
> > > 1) Prevent the listener socket from accepting any more connections.

> > Actually the problem is with listening thread. It is with already active
> > connections which has to be closed and if they are doing something with
> > sockets the only way to top them is to close all sockets. Closing all
> sockes
> > couses all these AV's which are handlend in the Execute method of
> > TIdPeeThread and then all threads are terminated.

> > The reason of timeout problems is mostly bad written OnExecute code.

> > > 2) Shutdown active connections gracefully.

> > You can't shutdown them gracefully becouse you have to force the close
> > operation and the only way is DisconnectSocket. Becouse it frees the
> Binding
> > property this couse the AV' sibn Recv or Send methods.

> > I can only advice you to update your indy sources and try with all new
> > changes we did in the last few days.

> > Doychin Bondzhev  - Team Indy

Re:AV with TIdTCPServer.Active := False ?


Ah...but the developer doesn't have explicit control over this.  Referencing
a component that has been freed is something that should be remedied. No?

Charles

"Doychin Bondzhev - Team Indy" <doyc...@dsoft-bg.com> wrote in message
news:3b90fe78_2@dnews...

Quote
> Exceptions does not accoure in the Kernelo or winsock. They occure becouse
> of freeing the TIdIOHandlerSocket.Binding property.

> "Charles Stack" <char...@codycomp.com> wrote in message
> news:3b90fde0$1_1@dnews...
> > Hmmm.  From what you've written the problem is that if you have an AV in
> the
> > kernel or in Winsock itself,  you  may not be able to catch it and
recover
> > gracefully.

> > There is no reason that you can't stop accepting connections on a
> listening
> > socket.  Just refuse the connection instead of accepting.  Then, you can
> > safely shutdown the other connections.

> > I will try the latest revisions to see if they make a difference.

> > Charles

> > "Doychin Bondzhev - Team Indy" <doyc...@dsoft-bg.com> wrote in message
> > news:3b90fa3a_2@dnews...
> > > > 1) Prevent the listener socket from accepting any more connections.

> > > Actually the problem is with listening thread. It is with already
active
> > > connections which has to be closed and if they are doing something
with
> > > sockets the only way to top them is to close all sockets. Closing all
> > sockes
> > > couses all these AV's which are handlend in the Execute method of
> > > TIdPeeThread and then all threads are terminated.

> > > The reason of timeout problems is mostly bad written OnExecute code.

> > > > 2) Shutdown active connections gracefully.

> > > You can't shutdown them gracefully becouse you have to force the close
> > > operation and the only way is DisconnectSocket. Becouse it frees the
> > Binding
> > > property this couse the AV' sibn Recv or Send methods.

> > > I can only advice you to update your indy sources and try with all new
> > > changes we did in the last few days.

> > > Doychin Bondzhev  - Team Indy

Re:AV with TIdTCPServer.Active := False ?


Quote
>sockes couses all these AV's which are handlend in the Execute method of
>TIdPeeThread and then all threads are terminated.

An AV should not be handled. It should be prevented.

Re:AV with TIdTCPServer.Active := False ?


Quote
>Exceptions does not accoure in the Kernelo or winsock. They occure
>becouse of freeing the TIdIOHandlerSocket.Binding property.

Then we should not be accessing them. Catching in AV is not a solution to
the problem.

Re:AV with TIdTCPServer.Active := False ?


I fixed the problem and it has to be OK now.

Quote
"Charles Stack" <char...@codycomp.com> wrote in message

news:3b910e9d$1_1@dnews...
Quote
> Ah...but the developer doesn't have explicit control over this.
Referencing
> a component that has been freed is something that should be remedied. No?

> Charles

> "Doychin Bondzhev - Team Indy" <doyc...@dsoft-bg.com> wrote in message
> news:3b90fe78_2@dnews...
> > Exceptions does not accoure in the Kernelo or winsock. They occure
becouse
> > of freeing the TIdIOHandlerSocket.Binding property.

> > "Charles Stack" <char...@codycomp.com> wrote in message
> > news:3b90fde0$1_1@dnews...
> > > Hmmm.  From what you've written the problem is that if you have an AV
in
> > the
> > > kernel or in Winsock itself,  you  may not be able to catch it and
> recover
> > > gracefully.

> > > There is no reason that you can't stop accepting connections on a
> > listening
> > > socket.  Just refuse the connection instead of accepting.  Then, you
can
> > > safely shutdown the other connections.

> > > I will try the latest revisions to see if they make a difference.

> > > Charles

> > > "Doychin Bondzhev - Team Indy" <doyc...@dsoft-bg.com> wrote in message
> > > news:3b90fa3a_2@dnews...
> > > > > 1) Prevent the listener socket from accepting any more
connections.

> > > > Actually the problem is with listening thread. It is with already
> active
> > > > connections which has to be closed and if they are doing something
> with
> > > > sockets the only way to top them is to close all sockets. Closing
all
> > > sockes
> > > > couses all these AV's which are handlend in the Execute method of
> > > > TIdPeeThread and then all threads are terminated.

> > > > The reason of timeout problems is mostly bad written OnExecute code.

> > > > > 2) Shutdown active connections gracefully.

> > > > You can't shutdown them gracefully becouse you have to force the
close
> > > > operation and the only way is DisconnectSocket. Becouse it frees the
> > > Binding
> > > > property this couse the AV' sibn Recv or Send methods.

> > > > I can only advice you to update your indy sources and try with all
new
> > > > changes we did in the last few days.

> > > > Doychin Bondzhev  - Team Indy

Re:AV with TIdTCPServer.Active := False ?


Thank you. <g>

"Hadi Hariri - Team Indy" <hadi...@pbe.com> wrote in message
news:3b914f7d_2@dnews...

Quote
> >sockes couses all these AV's which are handlend in the Execute method of
> >TIdPeeThread and then all threads are terminated.

> An AV should not be handled. It should be prevented.

Other Threads