Crash when debugging Unreal Engine project

I've been working on a project that uses the Unreal Engine (4.13, the latest version) and VS2015 (Update 3, all up to date afaik). Resharper C++ has been working pretty well: it's a significant improvement on vanilla VS and other competing extensions I've tried.

The major issue I have is that when I try to run with the debugger attached I get slow performance and VS eventually crashes or freezes and I have to force kill it. Problems usually occur within a few minutes, depending on how much I do and whether I hit breakpoints. 'Run' for this kind of project implies the Unreal Editor process executes and loads DLLs built from my code - sometimes this process survives but often I have to force-kill it as well. With Resharper C++ disabled I can run fine and haven't had any problems. When I get a crash dialog it refers to an unhandled .NET exception (coming from devenv.exe), but I haven't been able to attach to the process with another VS instance and get any useful info because the attaching VS instance becomes unstable too.

In the windows event viewer there are 'Application Error' and '.NET Runtime' Errors associated with the crash. The 'Application Error's come from KernelBase.dll and aren't that useful as far as I can tell:

Faulting application name: devenv.exe, version: 14.0.25420.1, time stamp: 0x57685d85
Faulting module name: KERNELBASE.dll, version: 10.0.14393.321, time stamp: 0x57f4c291
Exception code: 0xe0434352
Fault offset: 0x000da6f2
Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll
.. etc

The '.NET Runtime' Errors come from several different places, but a common theme is out-of-memory exceptions:

Application: devenv.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.OutOfMemoryException
at System.Windows.Media.Composition.DUCE+Channel.ReleaseOnChannel(ResourceHandle)
at System.Windows.Media.Composition.DUCE+MultiChannelResource.ReleaseOnChannel(Channel)
at System.Windows.Media.RenderData.System.Windows.Media.Composition.DUCE.IResource.ReleaseOnChannel(Channel)
at System.Windows.Media.Visual.DisconnectAttachedResource(System.Windows.Media.VisualProxyFlags, IResource)
at System.Windows.UIElement.RenderClose(System.Windows.Media.IDrawingContent)
... and the rest of the WPF stack

I've looked at memory use, as I suspect this is memory related: without Resharper C++ (but the built-in intellisense database enabled) the VS process uses about 600 MB and spawns a couple of other 800+ MB 'C++ Package Server' processes. With Resharper C++ enabled and the built-in database disabled there aren't any 'Package Server' processes (as I would expect) and the memory usage settles down to around 1.4 GB. When I run with the debugger attached the VS usage spikes up to above 2.6 GB.

I suspect this is one of those 'FFS why isn't Visual Studio 64-bit' issues, but if anyone is managing to debug a UE4-based project with Resharper C++ without crashing I would bother to investigate further. The size of my project doesn't compare to the size of the UE4 source, so if it's a memory thing I imagine others would have issues too.

I'd also be interested as to whether there are any plans to move the Resharper C++ database out-of-process, which might alleviate this problem?

 

1 comment
Comment actions Permalink

Jamie, thanks for the very detailed feedback!

You are correct, the cause for the crash is most probably OOM exceptions. Could you please try taking a memory snapshot with dotMemory (the instructions are at https://confluence.jetbrains.com/display/ReSharper/ReSharper+Profiling+Instructions) during a debugging session so we could take a look at how memory usage is distributed in your case?

If you have a chance, please try a 2016.3 EAP build from https://confluence.jetbrains.com/display/ReSharper/ReSharper+2016.3+EAP. We fixed an issue in 2016.3 and reduced the memory usage after loading from caches. On a full UE4 solution the difference was ~300mb, but it might be less for your project.

We do have plans - the best option would be to have the entire R# run out of process (which is possible - https://www.jetbrains.com/rider/ does that), but we don't have any timeline yet. Microsoft also promises improvements in VS 15 - quoting their slides from CppCon, "Memory usage during debugging significantly decreased. E.g. debugging a specific problematic project down to 1.9G from… crashing".

0

Please sign in to leave a comment.