Just some more informations about my software so you can have a better idea
on its working
My software is an IP Camera Surveillance app, so I have the server and the
client software, the server software (where it is raising the exception)
works actually as a server and a client, it has a server component to accept
incoming connection from my software client so it can deliver video to the
clients and it also acts as a client to receive video from the cameras, so,
I have a lot of tcp client instances inside the server (a connection per
camera) running on separated threads beacuse I can have lengthy operations
and a server instance.
Does the clients can affect on the server component any way?
One interesting thing is this:
Machine1: Access violation at address 7C8224B2 in module 'ntdll.dll'. Read
of address 00000003.
Machine2: Access violation at address 7C8224B2 in module 'ntdll.dll'. Read
of address C2289000.
On the first machine all the exceptions are raised at the read of address
00000003
On the second machine all the exceptions are raised at the read of address
C2289000
I have searched on the web for this kind of error and I got that it is
raised when a software calls a Windows API passing values when the function
is expecting a reference
I have tried to reproduce the access violation error calling Windows API
routines passing wrong reference values and it and in fact it raises those
exceptions like:
CreateFile(PChar(3), 0, 0, nil, 0, 0, 0);
This routine raises an access violation on ntdll.dll at a different address
(certainly because the address 7C8224B2 is from the routine that is raising
the exception on my server software) but it raises at the read of address
00000003 since I have passed a PChar(3) as a memory reference that the
routine was expecting
So, on ICS code, it cannot have any bug on accepting incoming connection
process that can be calling a Windows API passing wrong values?
> Do you find this text in OverbyteIcsWSocket.pas?
> { FP:26/09/06 Are FD_READ and FD_WRITE really necessary ? Probably not ! }
> { Lodewijk Ellen reported a problem with W2K3SP1 triggering an AV in }
> { accept. Keeping only FD_ACCEPT and FD_CLOSE solved the problem. }
> { Anyway, a listening socket doesn't send nor receive any data so those }
> { notification are useless. }
> Sounds like the same problem.
Yes, I have found it on the code, but it seems that it doesn´t really fixed
the problem
I couldn´t debug the software to get the error because I have WinXP and it
doesn´t raises this exception, but I´m sure that it is being raised when the
server accepts a connection from a client on Win2003, but as I said, it
doesn´t occurs frequently, but when occurs it crashes the software, look
this windows logs:
Error 3/6/2007 6:38:15 PM Servidor.exe None 0 N/A TECSRV10
Error 3/6/2007 6:38:07 PM Servidor.exe None 0 N/A TECSRV10
Error 3/6/2007 6:38:07 PM Servidor.exe None 0 N/A TECSRV10
Error 3/6/2007 6:38:07 PM Servidor.exe None 0 N/A TECSRV10
Error 3/6/2007 6:37:59 PM Servidor.exe None 0 N/A TECSRV10
Error 3/6/2007 6:37:59 PM Servidor.exe None 0 N/A TECSRV10
Error 3/6/2007 6:37:59 PM Servidor.exe None 0 N/A TECSRV10
Error 3/6/2007 6:37:51 PM Servidor.exe None 0 N/A TECSRV10
Error 3/6/2007 6:37:51 PM Servidor.exe None 0 N/A TECSRV10
Error 3/6/2007 6:37:51 PM Servidor.exe None 0 N/A TECSRV10
Error 3/6/2007 6:37:43 PM Servidor.exe None 0 N/A TECSRV10
Error 3/6/2007 6:37:43 PM Servidor.exe None 0 N/A TECSRV10
Error 3/6/2007 6:37:43 PM Servidor.exe None 0 N/A TECSRV10
Error 3/6/2007 6:37:35 PM Servidor.exe None 0 N/A TECSRV10
Error 3/6/2007 6:37:35 PM Servidor.exe None 0 N/A TECSRV10
Error 3/6/2007 6:37:35 PM Servidor.exe None 0 N/A TECSRV10
Error 3/6/2007 6:37:27 PM Servidor.exe None 0 N/A TECSRV10
Error 3/6/2007 6:37:27 PM Servidor.exe None 0 N/A TECSRV10
Error 3/6/2007 6:37:27 PM Servidor.exe None 0 N/A TECSRV10
This are the exceptions that are being raised on the server when the clients
connects to it, please, note that the interval between exceptions is 8
seconds. In this case I have 3 clients trying to connect to the server at an
interval of 8 seconds (This is a behavour of my client software, it tries to
reconnect to the server if it loses the connection at an interval os 8
seconds)
Any ideas?
Thanks!
Éric
Do you find this text in OverbyteIcsWSocket.pas?
{ FP:26/09/06 Are FD_READ and FD_WRITE really necessary ? Probably not ! }
{ Lodewijk Ellen reported a problem with W2K3SP1 triggering an AV in }
{ accept. Keeping only FD_ACCEPT and FD_CLOSE solved the problem. }
{ Anyway, a listening socket doesn't send nor receive any data so those }
{ notification are useless. }
Sounds like the same problem.
--
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
Éric Fleming Bonilha wrote:
> Hello all!
>
> I´m having a strange problem on my app using ICS 6, I have noticed
> that my server service raises an exception "Access violation at
> address 7C8224B2 in module 'ntdll.dll'" but I didn´t got where the
> problem is happening, analysing the error logs I realised that this
> error is being raised when a client tries to connect to the server,
> but this error is just happening on Windows 2003, on XP is OK and the
> strange is that has no time to occur, it works fine for the most of
> the time, but sometimes it starts raising those exceptions and my
> server sofware crashes.
>
> I have searched on google for this error and I saw a message that was
> sent to this list that another user had the same problem as me and it
> was said that the user has changed some lines of code on ICS and
> solved it
>
> This problem is happening on a lot of mine customers using Windows
> 2003, on WIndows XP it doesn´t happens
>
> Any Ideas????
>
> Following is the message that Fraçois wrote about the problem:
>
> Thanks!!!
> Éric
>
>
>
>>
>> A user reported to me that winsock.accept generate an access
>> violation at address 7C8224B2 in ntdll.dll when is program runs on a
>> w2K3 SP1 computer, and only one such computer. He found that
>> changing the lines:
>>
>> FSelectEvent := FD_READ or FD_WRITE or
>> FD_ACCEPT or FD_CLOSE;
>> iStatus := WSocket_WSAASyncSelect(FHSocket, Handle,
>> WM_ASYNCSELECT,
>> FSelectEvent);
>>
>> into:
>> FSelectEvent := FD_ACCEPT; // Not all events, other wise Access
>> violation 7C8224B2 in NtDll in Window 2003 sp1.
>> iStatus := WSocket_WSAASyncSelect(FHSocket, Handle,
>> WM_ASYNCSELECT,
>> FSelectEvent);
>>
>> solved the problem.
>> Any one else noticed similar problem ?
>> Removing FD_READ and FD_WRITE has probably no impact on a listening
>> socket.
>> But removing FD_CLOSE probably has (I have yet to do some testing).
>>
>> Any tought ?
>>
>> Than
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
