Spring & related apps got a "freeze" bug in 0,80,2

[reivanen]

I already posted about this in the news section, but that is totally wrong forum, so i will post this here, as a complete info set instead of random posts.

So the problem started when i installed 0,80,2 Spring. I immediately noticed that launching the springsettings after setup did not happen, even though i had checked the box. Well, actually it did eventually, but my system just sat doing apparently nothing for something like 5-8 seconds. After this, the normal loading indications appeared and it launched normally.

The exact same thing happens when i try to launch a multiplayer battle, my spring starts loading when others are already ingame. Or when i launch spring.exe directly. The cursor first goes to background process activity, then to no activity, then it starts actual loading and shows the new splash screen. When i click launch in the splash screen, it starts loading immediately like in previous versions.

Tasclient also spends some 5 seconds of doing nothing during "initializing unitsync" after which it starts the real initialization loading. "Initializing archivescanner" Does the same and reading mod file. Here i know the real loading starts when the window goes grey (win7 feature prolly) and the title switches to show (not responding).

Same story with springlobby latest. It freezes for doing nothing during similar situations.

When i look at the spring.exe process for instance, it goes to 15-16megs ram usage and 50% CPU usage (100% one core) during the "doing nothing" phase. After this the ram usage and cpu usage starts to fluctuate like it does when it actually loads. The same 100% cpu happens with tasclient, springsettings, springlobby, spring.

Only springdownloader seems to be unaffected by this.

Is anyone else having this problem?

The only thing that changed in my system was spring version when it started happening. I removed all the hidden related folders and spring itself and did a true clean install. And no, its not just "normal loading" and me being impatient.

Devs: Does this sound like something related to unitsync? Did anything change in 0,80,2 in unitsync? Did previous 0,8 branch versions have different unitsync then latest? Would it be worth obtaining one of those and see if it still happens?

Next task is playing around with system monitor to see what io activity takes place during the freeze.

edit: win7 rtm c2d gtx285 latest whql

[reivanen]

I have been struggling with this problem since the update, and now, magically while i was playing around with resource monitor checking disk io and launching and closing tasclient, spring and springsettings several times, it magically started working like before!

I thought it must be something cached since the massive amount of run/close but after a restart it still worked like a charm!

So for now, this case seems to be closed.

[zerver]

Good to hear it is solved.

When you have that many apps misbehaving (apps with very little in common!) it is reasonable to suspect there is something wrong with your system rather than the apps

[reivanen]

Good to hear it is solved.

When you have that many apps misbehaving (apps with very little in common!) it is reasonable to suspect there is something wrong with your system rather than the apps

So i was incorrect to assume all the described errors were when apps used unitsync?

I would suspect the error was system related, if it happened on anything else then apps that came with 0,8,2 (i tested even reinstalling older version of spring somewhere in between and the error disappeared, only to reappear after installing new again)

But for now it seems to have solved itself :)

[zerver]

Could have been unitsync related I guess, but these progs use unitsync in quite different ways and Spring itself does not use unitsync at all. I'm not sure if springsettings uses it either.