OMFG! 1.5.2 builds on Linux

#21 Lee, its stock.

I unzipped the windows version, copied the directory over to the linux box, did a build there, and using that binary on the server and the one shipped with the windows for the client. The client also 'freezes' when the server does, for like a second, then yields, then freezes again, etc...no errors reported on either client or server.

I have tried building release and debug on both windows and linux systems, using the stock code. Same result each time. However, the 1.5 linux server works just fine on the same systems, except of course its downlevel and I cant use it with the latest release.

Thanks!

#22 Try a different server machine? Different client?

My feeling is that it's more likely a system level issue, ie. some process is kicking in and sucking up cpu cycles intermittently.

#23 Thanks Lee...I was thinking the same. I am running the server on blade servers, so I will test on different hw for the server and see.

#24 Well, I did the build on a laptop this time to eliminate hw and system level specific issues. Again it builds just fine, and again the server intermittently locks up, just like before.

Is it possible this is related to the -dsleep latency feature? I was poking around the platformX86UNIX files, but it was not clear to me if that is the issue.

I am assuming that everyone else that got 1.5.2 to build on linux does not have this issue? What am I doing wrong, something in the build, environment, etc???

#25 @Michael - I found a similar problem to yourself with it freezing for periods of time, what I did was then turning on the profiler and waiting for a couple of minutes then doing a dump, not sure if you're familiar with the commands but if not then in script you can use the following:

profilerenable(1);  // turns on the profiler and starts gathering statistics
profilerdump(); // outputs the gathered stats to the console

that showed me this:

------------- ROOT ----------------

100.000   0.000       46    MainLoop

 99.868   0.000       46      PlatformProcessMain

 99.868   0.001       46        XUX_PlatformProcess

 99.867  99.867       46          XUX_Sleep

Which as you can see XUX_SLeep was taking up 99.8% of the time, I can then search through the code to find the section that acts as culprit (see below), for it was the sleep function which I've commented out for now and problem solved. I'll have to figure out the proper solution some other time.

#26 Andy, thank you! That was it. I had been messing with the -dsleep option and code but just commenting it out for now did the trick. Also good to know about the profiler for the future. Now we are cooking with GAS! Thanks again!

#27 There's also always the strace option, and waiting to see what system call is causing it to lock.

Gary (-;