WideClient stops

[CATIII]

Dear Pete,

with the latest FSUIPC/WideFS I get some serious errors which make WideClient stop working. On the client host, I have 2 applications running using FSUIPC. The error appears after a few minutes only. On the task manager nothing changes concerning wideclient.exe.

The error message shows up if wideclient is stopped manually with the mouse. You can have a look at the logfile here:

http://www.unixland.de/sim3sim/wideclient.zip

Thanks for your help!

Best regards,

--CATIII

PS: Attached you see the Wideserver.log. The affected computer name is 'IOS'.

********* WideServer.DLL Log [version 6.414] *********

Blocksize guide = 4096 (double allowed)

Date (dmy): 29/11/04, Time 09:58:41.031: Server name is ACFT

18640 Initialising TCP/IP server

18640 Initialising IPX/SPX server

18640 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family

18640 Failed to start IPX/SPX Server

41187 Restarting service due to total lack of use

41203 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family

41203 Failed to start IPX/SPX Server

63750 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family

63750 Failed to start IPX/SPX Server

86250 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family

86250 Failed to start IPX/SPX Server

108937 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family

108937 Failed to start IPX/SPX Server

131640 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family

131640 Failed to start IPX/SPX Server

154343 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family

154343 Failed to start IPX/SPX Server

177000 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family

177000 Failed to start IPX/SPX Server

199687 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family

199687 Failed to start IPX/SPX Server

222343 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family

222343 Failed to start IPX/SPX Server

244890 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family

244890 Failed to start IPX/SPX Server

267593 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family

267593 Failed to start IPX/SPX Server

290218 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family

290218 Failed to start IPX/SPX Server

312750 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family

312750 Failed to start IPX/SPX Server

335437 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family

335437 Failed to start IPX/SPX Server

358140 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family

358140 Failed to start IPX/SPX Server

380843 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family

380843 Failed to start IPX/SPX Server

403484 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family

403484 Failed to start IPX/SPX Server

426187 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family

426187 Failed to start IPX/SPX Server

448890 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family

448890 Failed to start IPX/SPX Server

455843 Incoming connection Accepted ok (skt=288)

455843 Connected to computer "IOS" (skt=288)

3919453 Incoming connection Accepted ok (skt=4880)

3919781 Connected to computer "CPT-CDU" (skt=4880)

3921593 Incoming connection Accepted ok (skt=4892)

3921828 Connected to computer "FO-MFD" (skt=4892)

3923234 Incoming connection Accepted ok (skt=4888)

3923515 Connected to computer "CPT-MFD" (skt=4888)

3925875 Error 10054: client socket disconnected at Client: removing (skt=288)

3928890 Incoming connection Accepted ok (skt=308)

3929172 Connected to computer "FO-CDU" (skt=308)

3934812 Incoming connection Accepted ok (skt=296)

3937109 Connected to computer "MAP" (skt=296)

3944203 Incoming connection Accepted ok (skt=4928)

3944718 Connected to computer "EICAS" (skt=4928)

4358328 Incoming connection Accepted ok (skt=4964)

4358328 Connected to computer "IOS" (skt=4964)

7800531 Incoming connection Accepted ok (skt=4980)

7800562 Error 10053: client socket disconnected at Client: removing (skt=4964)

[Pete Dowson]

with the latest FSUIPC/WideFS I get some serious errors which make WideClient stop working.

You appear to have all sorts of serious errors which I've never seen before.

On the client host, I have 2 applications running using FSUIPC. The error appears after a few minutes only. On the task manager nothing changes concerning wideclient.exe.

But the log shows nothing going wrong for a long time! the first error logged is after 3212 seconds (over 53 minutes!).

3212984 Error: couldn't allocate buffer to receive response (126976 bytes)!

3212984 Send depth is 54 (Max 0)

3214625 Send() request depth is over 100! Will re-connect:

3214640 Attempting to connect now

3217828 Connection made okay!

3219031 Error: couldn't allocate buffer to send a request (3652 bytes)!

The "couldn't allocate buffer" message is also most peculiar (I've never seen it do that before either), but then 126976 bytes is rather a lot -- the largest block normally handled by WideFS is 31000 bytes.

What are you seeing happen "after a few minutes only", just that message box? I've never seen that before and have no idea what it means I'm afraid. That is something in the run-time library installed on that PC. You say:

The error message shows up if wideclient is stopped manually with the mouse.

What does "stopped manually with the mouse" mean? I don't understand that. And if you'd "stopped" it, how is it carrying on for 53+ minutes?

What operating system are you using on each client, this one in particular, and the Server?

PS: Attached you see the Wideserver.log. The affected computer name is 'IOS'.

I don't think the Server should be throwing up those errors:

41203 IPX/SPX socket() failed [Error=10047] Address family not supported by protocol family

Provided it gets at least one of the two protocols it shouldn't be raising any errors for the other -- but i'll double check that here.

I assume your other clients are okay, so do you mind telling me what's unique about the problem one? Is it, do you think, related to the applications you run there (try moving them and running something else, just to see)? Or is it something different about the operating system, memory, and so on?

Regards,

Pete

[CATIII]

Pete,

thank you for your reply. In the meantime I did some more investigation on this problem. My application has been run on different computers with different operating systems. I was able to reproduce the error by synchronizing FS-time with local time (and date). The affected procedure has not changed the last 6 months but for some reason it crashed WideClient (and sometimes even FS9).

After reverting everything to WideFS 6.41 and FSUIPC 3.411 the error is gone. Maybe a mixture of different versions of Wideclient in my setup was causing the crash. Maybe something else caused it but today everything is running properly for 12+ hours.

If the error appears again I'll be trying to track it down more precisely. That's a promise 8)

Best regards,

Michael (CATIII)

[Pete Dowson]

I was able to reproduce the error by synchronizing FS-time with local time (and date).

I'm not sure what you mean by that. I use FSRealTime for that function -- I run it on a Client. When it first sets the time correctly it certainly makes FS reload scenery -- any change of more than a short time does that. But it doesn't crash anything. What exactly are you doing to "synchronise FS time with local time"?

I suggested a process of elimination by moving things around, to see if it related to that Client or is more something to do with an application.

I also couldn't make sense of some of the things you said in your initial report, and I asked you about them. As I pointed out, the Log you provided didn't match what you were saying. I haven't been able to make use of anything you've offered here I'm afraid.

Are you simply going to retreat to older versions with no further explanation of what you were talking about?

Anyway, you do what you have to do, but, I'm sorry, but I will not be supporting old versions.

Regards,

Pete

[CATIII]

Hi Pete,

let me try to explain some things concerning my last posts. My application often crashed after a few minutes of operation. However, the log file was saved from a session which lasted obviously longer. I didn't check that. Sorry!

For time synchronization I'm using a self-written procedure that adjusts FS time and date according to local time when a button is pressed. This causes a wideclient crash with the latest test versions, so I must have a look at this procedure.

After Wideclient doesn't run anymore (no blinking on my network switch) I killed the task Wideclient.exe in the W2K task manager. While the OS kills the process, the error message appears. After pressing OK, Wideclient is ready for another restart.

My application has been run now on W2K, WinXP and WinME. The OS doesn't make a difference. I'm quite sure that my time syncing function does something bad which worked before (at least before updating to FS9.1).

With my original post I didn't want to blame you on the error. Just wanted to look for some help. Furthermore I wouldn't dare to request support for old versions.

Currently I don't have the time to re-program something, but I will keep you posted as soon as my problem is solved.

I hope my point is clearer now.

Best regards,

CATIII

[Pete Dowson]

For time synchronization I'm using a self-written procedure that adjusts FS time and date according to local time when a button is pressed. This causes a wideclient crash with the latest test versions, so I must have a look at this procedure.

If you have a program that can so easily crash or hang WideClient, I'd like to try it here, please, as I need to find out why. It is EASY to crash FS with an application, because you are allowed to write to so many places in FS which FS can get grumpy about. but WideClient should just pass things on.

So, if you can supply something which will do it on my system, perhaps you could put it together with instructions. ZIP it all up and send it to me at petedowson@btconnect.com, please. I am trying to wrap things up (new WideFS and FSUIPC) for late next week, or at most the week after, if possible.

Please note that one of the changes in 6.414 was to do away with the "Timeout" parameter (which defaulted to 12). It is "renamed" the ApplicationDelay, to more accurately reflect what it actually does, and the new default is 0. This was after testing many client programs and finding they all run perfectly well with no delay in WideClient before returning control to the calling application after every Process request.

The only reason there was a delay in the first place was that some programs seemed to sit in such a tight loop calling FSUIPC_Process that once they were running nothing else got a look in, making the whole PC difficult to deal with.

To make the same effect as the original default Timeout=12 you need to set ApplicationDelay=6 (the original was halved way back in Version 5).

After Wideclient doesn't run anymore (no blinking on my network switch) I killed the task Wideclient.exe in the W2K task manager. While the OS kills the process, the error message appears.

Aha! I see. Oh, in that case it isn't really relevant. The error is likely because there are multiple threads in WideClient (more in 6.414 than in 6.41 in fact), and the crude process killing method probably kills them in an order which upsets the thread sharing parts of WinSock.

I'm quite sure that my time syncing function does something bad which worked before (at least before updating to FS9.1).

Try the ApplicationDelay change. If that makes it work in 6.414, try 6.41 again but set Timeout=0. This should make them similar as far as your program is concerned. Let me know please.

I hope my point is clearer now.

Yes, very much so. Thanks. If possible, I would still like to try things here, even if the delay change does help. I would like to avoid any possibility of WideClient appearing hung -- I'd need to take steps if this is caused by very tight loops at the application/process interface.

Regards,

Pete