5.2.0p1: P4 version control hangs editor due to fstat spam bug

This problem only started showing up in 5.2.0p1, and I suspect it's related to this change:

"(715960) - Version Control: Do not use cached status for checking editability in VCS."

In 5.2.0p1, any time you select any version-controlled asset (i.e. anything in your Project tab), the editor immediately becomes unresponsive (on Mac, it beachballs). If you look at the p4plugin.log file, it shows that P4 is spamming the fstat command for the asset you just selected:

"fstat "[path]/Assets/Scripts/PopulateResolutionDropdown.cs.meta"

That message repeats over and over and over, during which time the editor is completely frozen. If you click around in the frozen editor to deselect the asset in the Project tab, the click will eventually get through on Mac and quit the beach-balling, but that doesn't appear to work on Windows. On Windows the freeze is unrecoverable.

In short, the nonstop fstat commands make the 5.2.0p1 editor completely unusable in a project that uses P4 for version control.

Reported as #728723.

 

Yep. Seeing the same thing in 5.2.0p1 with similar symptoms. In Windows, I don't totally freeze up, but the editor feels like it's running at about 2 hz. p4plugin.log shows continuous spamming fstat of the same file. The only way to make the editor usable is to set 'work offline' mode in the Perforce plugin settings.

I can't roll this out to our team.

 

OneThree, is your Perforce server on your LAN or do you connect to it over the internet? I tested 5.2.0p1 today from a computer connected to the same LAN as our Perforce server, and the editor was not performing as poorly. Perhaps this issue is magnified when response time to/from the Perforce server is longer?

 

I just tried 5.2.1f1 and unfortunately, this problem still exists.

 

I filed a bug report for this, too, from 5.2.1f1. Case 729709.

 

Problem still exists in the patch that was just released, 5.2.1p1. Still can't roll out 5.2 to our team because of this.

 

Hi, Leon, just now saw your replies. Our P4 server is hosted by AWS, so it is remote. We've never had any speed issues with it, though, so I assume it's a pretty fast connection.

 

I'm experiencing this problem as well. It is keeping our team from upgrading to 5.2.

 

We are experiencing the same problem. Our P4 server is hosted on LAN. Selecting an asset makes the editor perform horribly.

 

Same problem here, though I didn't see it come up until 5.2.1f

 

We have the same problem with Plastic SCM, and we can't update to 5.2.1 for our team too. I didn't find where can I wote for the problem by case number

 

Hello everyone! I have seen some chatter on Twitter regarding this issue and wanted to provide you with an update. The issue is being worked on for the 5.3 release. The issue has been marked as "Necessary for shipping final release" which is a good thing!

TL;DR - watch for fix in 5.3!

 

Any chance of a 5.2 patch? The main project I'm working on I don't think is ready for being updated to many of the changes in 5.3 (like multi-scene API stuff).

 

As far as I know, no. I'll send the devs a message and see what they say

 

Thank you! I really appreciate it.

 

No, this is a very bad thing.

Our project is on 5.2.0f3, which is very buggy, and we really need a number of the 5.2.1+ animation fixes, not to mention the other fixes. We can't downgrade our project, meaning we are now stuck with a bad, unstable version of Unity for over two months now. This impacts our schedule badly, not to mention how unpleasant it is to use 5.2.0f3 every day. It crashes constantly, there's the "failed to move file" bug ... hell, you can't even sort your hierarchy alphabetically.

The fact that version control makes the editor unusable doesn't get enough attention on this bug to have it fixed in less than 2+ months?

 

I understand its frustrating. </3 The good part is, its *actively* being worked on. They may backport it once it has a fix, but I can't guarantee that so I don't want you to count on it. I've added the issue to my personal watch list. If something changes, I'll post here and update you.

 

It's not just frustrating. It quite literally costs us time and money.

It's one thing for there to be bugs with new features or overhauled systems, which may need several versions to get right. It's quite another for bugs and regressions to appear in previously stable systems that projects depend on. Promptly addressing those categories of issues should be the absolute highest priority of a middleware vendor; they have a very direct, significant (negative) impact on both the cost of our projects and the eventual chances of success.

Bugs and regressions in stable systems need to be addressed asap in the same version line where the bugs were introduced, not in a hypothetical future version months away with an even more hypothetical (and opaque) possibility of being backported one day.

Short version: these sorts of bugs and regressions are the absolute worst sorts of bugs for an ongoing project. Please consider addressing this asap in 5.2.

 

Well-said, Leon. This puts our alpha deadline at risk.

Given that developers cannot roll back upgraded projects, it's difficult to understand a set of priorities for the Unity team where breaking source control and trapping developers with an extremely buggy version of the editor for literally months would not call for an all-hands-on-deck approach to fixing this bug ASAP.

And here's another question: why not roll back the change in 5.2.0p1 that caused this regression?

P4 was working flawlessly for us before that change; why can't that change -- which clearly was not tested enough -- be rolled back until a real fix can be put in and properly tested? Perhaps rolling it back could even be exposed as an option in the editor's version control settings so that teams who aren't having this issue in 5.2.1 can keep rolling forward.

Anything is better than "You guys are screwed for two months."

 

To be fair, P4 integration was not working 100% reliably for us before this; lots of edits were being missed by it, assets were often (incorrectly) appearing in the inspector as editable, only to eventually become grayed-out and the 'check out' button to appear, etc. So I definitely don't blame anyone for trying to fix its problems. It's just that the attempted fix resulted in an unusable editor, whereas the previous problems were annoying but not fatal.

 

Also, I didn't mean to be rude in my previous message; I realize it may come across that way. I am just frustrated because this is not an isolated occurrence. I spend an unsettling amount of time every day on these forums trying to track down why things don't work, when they will be fixed, etc, so I can a) get stuff working or b) at least plan for when things will be working. What is happening here with this bug is a very common pattern: future versions with new features being heavily prioritized over stabilizing released versions that people are trying to ship products with.

So, apologies if this thread is getting a little warm. It is out of frustration with the apparent release priorities of the Unity 5 line. I am relatively new to Unity, about a year now, so maybe this is normal? We're basically pleading for help, not trying to throw anger toward anyone.

 

Thanks, Jonas!

 

Cool, looking forward to that.

 

Thanks so much! It's a huge relief knowing that we won't have to wait until 5.3 for this. We very much appreciate your quick attention and fix.

 

Please, check if fix solve this problem for plastic as well

 

Thank you, you all rock! (both Unity team, and the users who helped narrow down the issue)

 

oh man if this gets patched for 5.2 it will be so so nice.

 

looking forward to this patch. Been struggling on with a laggy editor window for the last couple of weeks.

 

By the way, as we are still waiting for patch, I have one more question about version controll. Now folder renaming in Unity is treated like deleting old one and creating new one by Plastic plugin. We've emailed this to Plastic team and they answered that it was Unity bug and they had created bug report. I wonder if jdrewsen is aware of this problem or this bug report will get dusty somewhere for ages?

 

A new patch has just dropped. Sadly I don't see a fix for this issue in the changelog

 

Yeah, I wasn't expecting it for p3, as it was pretty near release by the time jdrewsen came in here. Hopefully next patch though =-)

 

Has anyone tried the new patch yet? I really want to stay on top of this one for you.
https://unity3d.com/unity/qa/patch-releases

 

Yeah - I've tried p3... it didn't fix the issue so far as I could tell.

 

I don't mean this to sound rude, but wouldn't it be faster to just ask the developer who made the fix? They should be able to see if their checkin was included in a given release.

 

Dunno, I haven't tried the last two patches because they broke something even more fundamental to our projects than Perforce: occlusion culling + realtime lights (http://forum.unity3d.com/threads/un...orking-occlusion-problem.358661/#post-2336025). OT here, but...could you also jump over to that thread when you get a chance and maybe poke around on the dev side to see what's going on?

 

Thanks for the update, jdrewson.

 

Thanks, this was a huge issue for us.

 

I can confirm that this is fixed for us using P4, but the lighting bug linked by Leon above makes our entire game pitch black.

So we have to choose between staying with the incredibly buggy 5.2.0f3 build or updating to 5.2.1p4, getting a ton of helpful fixes, and having to either run our game at a terrible framerate (due to clearing occlusion data) or figuring out a way to disable shadows in a way that we can undo easily later without having to go by hand through the whole scene.

5.2 has been really, really disappointing from a stability and quality control standpoint. Unity needs to figure out how to put better testing and QA practices in place; what's there now is not working.

 

A fix might have been put in place, but confirming it in the "field" is always a good idea <3

 

I agree, but when you asked the fix wasn't in the field. So people would have wasted an hour or two of their workday uninstalling/installing Unity versions only to find the fix wasn't in p3.

 

p4 works for me! Thanks!

 

I also was running into this problem, downloading the P4 patch now to see if it resolves the issue (and hopefully our lighting still works)

 

I have the same problem on 5.3.2p1.... I can't inspect nothing when the game is running that unity becomes very unresponsive and slow.

 

I found the problem, it was my fault. I had a bug within my save game and I had a 5mb save game loaded on inspector which was the cause it was so slow when inspecting.

 

This still seems to happen as of 5.3.1p3 on very large project. A workaround is to no ever use the Version Control window and set the Log Level in perforce Editor Settings to Fatal. This fixed my Windows machine YMMV.