Connecting to source control causes project to close

Development Programming & Scripting C++
, , ,
1

I’ve had a lot of trouble with this and have finally narrowed it down.
connecting a project to source control from inside the editor causes the project to close 3 seconds after it is opened the next time.

this happens on every machine. 3 tested.

2

Hello GBrodeur,

Would you be able to provide a crash log to us so that we may view what’s going on. Also, which provider are you connecting to when connecting to Source Control?

Thanks,

-W

3

I am hosting Subversion on a Lan Server on a windows machine. its running SubversionEdge,

link text

4

Hi,

The log posted above reads like the Editor was simply closed, which is certainly odd. I will look at this tomorrow to try to determine what is happening, but are you certain that this was the log generated when the editor closed by itself?

What version of SVN did you install into your ThirdParty binaries directory?

5

indeed it was generated at the time of the crash… the problem is quite easily replicated. If i create a new project. all is fine. editor works as you would expect. i can save, or not save, close the editor, and later open the project and have no issues.

If i add the project folder and contents to repo via windows shell. no problems. the project will open, the levels will open nothing closes all is well.

if i ask the project inside the editor to connect to source control it will without issue. after it connects it does not matter what i do or do not do. if i simply connect to sc then close the editor, it will gracefully terminate like normal. opening the project afterward will cause the editor to close approx 3 seconds after opening.

I have tried creating a brand new test repository and recompiling from source (versioning everything before 1st launch as to avoid versioning cache data) and re testing. same results on all machines in the local network. as well as any outside.

I am currently testing to see if the occurs with an earlier QA build from CL 1897729, so far it connects without issue i can reopen projects and project is still connected to source.

and the only directories under engine/binaries/thirdparty/ are the stock directories. Angle, imgtec, ionic, ios, mcpp, mono, nvtexturetools, ogg, openal, physx, sdl, svn, vorbis.

6

Sorry, just to clarify something: Are you running the version 4.0.1 downloaded via the launcher? This version did not include the SVN binaries out-of-the-box, so required you to install it separately. If not, what version are you running?

This is not something we are seeing here at all. Are you able to build from source & add a breakpoint to determine what is causing the CLOSE_SLATE_MAINFRAME command to be queued (this is in your log)? This is usually only done as a result of user action & there are 4 locations it can be called from in our current version.

7

No not from launcher. Compiled from source from Git, I even tried re cloning from git and recompiling. exact same results.
sorry but i’m unfamiliar with adding breakpoints.

8

So after a lot more testing. I have been able to create a circumstance where I can connect to source and not have the project crash.

I have created 2 test repositories.

The 1st has the engine compiled from source, a project created, connected to source, saved and user closed. I can reopen the project and assets will update their status and the editor remains open.

The 2nd has the engine compiled from source and all files versioned before 1st launch (to avoid versioning any precompiled shaders, temp files etc) a new project created, connected to source, saved and user closed. After reopening the project, the editor closes, however it is now spitting back some proper errors. I’ll have the log file attached i cant make sense of itlink text

not to sure why this happens as its not like svn locks files or makes them read only like perforce. the only time it does is if another user issues a lock and a different client updates. files remain writeable to even if I were to version a config file or something temp by accident it can still be overwritten or changed.

Is there some files generated files that I should not be versioning?

9

Much more interesting! This log contains a crash, rather than a shutdown, although it does not give me any callstack information, it indicates that one of the worker threads crashed (possibly the source control thread). Could you run this with a debugger attached and post me the callstack?

10

We can confirm this problem. It crashes for us too when restarting the editor, so for now we are working without the SVN plugin. Our repository does not have any generated or intermediate files in it.

11

link text

12

Thanks for that log, but that doesn’t contain a callstack either, it seems to be a log of the editor startup in Visual Studio.

To generate a callstack, follow these instructions:

  • Make sure you have UnrealVS installed, as this makes things easier (instructions here).
  • Build your game’s project in Visual Studio.
  • Enter the full path to your .uproject file for you game into the command-line box in the UnrealVS toolbar (this is the right-most text box in the toolbar).
  • Press F5 to run the Editor with your project.
  • If/when it crashes, open up the “Call Stack” tab (from the Debug->Windows menu). Right click in the window & click ‘select all’ then ‘copy’ & paste that here.

Thanks for the help with this!

13

Apologies, but there is a small change to the above instructions as I was using an older version of UnrealVS.

In the released version you should not need to do step 3 (enter the full path… etc.) because as long as UnrealVS is running it will auto-add your uproject to the command line.

(One exception to mention is that if your game project doesn’t end with ‘Game’, or your solution doesn’t begin with ‘UE4’ or your build config doesn’t end with ‘Editor’ then UnrealVS wont auto-add the command line and the above instructions still apply).

14

sorry. haven’t forgotten. just still trying to set up UVS

15

Hi,

I have recently found and fixed an issue that looks to be the root cause of the startup crashes some people are seeing when using Subversion. It is a buffer overrun in the XML Parser. Unfortunately the fix might not get into the official build until 4.2, but those people building from source can apply the following patch to address it:

In \Engine\Source\Developer\XmlParser\Private\XmlFile.cpp:

73		// Parse input buffer into an array of lines
74		SplitLines(Input, *InFile, sizeof(TCHAR) * InFile.Len());

Becomes:

73		// Parse input buffer into an array of lines
74		SplitLines(Input, *InFile, InFile.Len());
16

I just received word that this was integrated into 4.1 after all, so people suffering from this issue wont have to wait so long!