Exception with perforce in UnrealEditor

I get an unhandled exception when UnrealEditor attempts to construct a FPerforceConnection. I was able to track the exception down into the first call to FPerforceConnection::RunCommand with “info” as the InCommand. If I am debugging with VS2013, VS catches the exception and if I ask it to continue then everything runs fine and perforce operations run normally at that point. When not in VS, I’m unable to proceed at all. So I was able to “resolve” by making the following changes…

P4ClientRun(P4Client, FROM_TCHAR(*InCommand, bIsUnicode), &User);
// P4Client.Run(FROM_TCHAR(*InCommand, bIsUnicode), &User);

void P4ClientRun(ClientApi & P4Client, const char *func, ClientUser *ui)
{
	__try
	{
		P4Client.Run(func, ui);
	}
	__except (EXCEPTION_EXECUTE_HANDLER)
	{
	}
}

What’s weird is that my coworkers are not having this problem. Only me. Originally, I installed the newest version of perforce (I’m the newest addition to my company), but I downgraded to a version that most of my other coworkers were using. So at this point, we have the same version of perforce and I build and supply them all with the binaries that they use to run UnrealEditor. Can this exception wrapper be added to the official codebase?

Hi,

It sounds like there is another underlying issue at play here. Adding ‘sink’ try/catch blocks wherever you might get an exception is never good practice :wink:

It sounds as if you were able to trap this in the debugger already - what were the values of InCommand and User?

Hi Tom,

Thank you for responding - I really do appreciate you trying to help.

Of course I would never just blindly add a try/catch/except to resolve an issue. But in this case, you are executing an encompassing command through a perforce plugin that is not provided as source. Additionally, the comment for FPerforceConnection.RunCommand is “Runs internal perforce command, catches exceptions, returns results”. It appears that it is not catching all exceptions as intended hence I felt little worry with my code after verifying everything was working - the alternative being that UnrealEditor simply crashed due to the exception within the perforce library.

As mentioned previously InCommand is set to “info” and User is the default data that normally exists for a first time call. With my exception handling, it does appear to get filled in by the P4Client.Run command - though the data is masked so I would need more information on what calls/info you would like after the P4ClientRun command returns.

Cheers,

Not a problem, its what we are here for!

It may indeed be so that we want this try/catch block - the external code may fire off random exceptions, it is perfectly legal to do so after all!

As an aside, some users have reported odd exceptions in the Perforce plugin when using certain VPN software, such as Astrill. Could this be an issue for you? If so it is on our backlog to investigate.

First of all, do you know what exception was fired? We have seen stack overflows in this code in the past.

Secondly, the interesting information is contained in the ArgC and ArgV variables in that function. Do you have access to them?

I am not using a VPN - so that’s not the issue.

I added the following code in the __except block…
UE_LOG(LogSourceControl, Warning, TEXT(“Exception: 0x%08X”), GetExceptionCode());
At that point, I get two exceptions 0xC00000FD (stack overflow) and then 0xC0000005 (access violation) - what was the resolution for stack overflow in the past?

ArgC is 0 and ArgV is address that points to another address that points to a null address.

Unfortunately we have not yet been able to reproduce the stack overflow issue on connection internally. From what we can tell it is very dependent on user’s configuration. We have had reports that indicate that installing/uninstalling different Perforce versions could potentially affect this issue too, so that at least may be a common factor here.

I’m still wary of adding the try/catch block as it may result in hiding incorrect functionality, especially when we cannot reproduce the issue here.

Do you have any call stack information available to you? Even one lacking symbols for the parts in external dlls might help.