SRW Lock issues raised by Application Verifier.

Hi Epic,

We’ve been playing around with Application Verifier on our project, and it has raised a couple of issues on our project, but also a little bit on Unreal Engine. Most areas are perfect - but a couple came in from SRW lock validations.

1. RigVMRegistry.h

// Returns the type index given a cpp type and a type object
TRigVMTypeIndex GetTypeIndex(const FName& InCPPType, UObject* InCPPTypeObject, bool bLockRegistry = true) const
{
  FConditionalReadScopeLock _(*this, bLockRegistry);
  return GetTypeIndex(FRigVMTemplateArgumentType(InCPPType, InCPPTypeObject));
}

This function locks - then calls another function that also locks (SRW locks shouldn’t be used recursively). We replaced this with “Super::GetTypeIndex_NoLock(FRigVMTemplateArgumentType(InCPPType, InCPPTypeObject));”, although removing the lock is also an option as long as you pass through bLockRegistry.

2. DerivedDataCacheStoreHierarchy.cpp

template <typename Params>
void FCacheStoreHierarchy::TGetBatch<Params>::CompleteRequest(FGetResponse&& Response)
{
  ...
  FReadScopeLock Lock(Hierarchy.NodesLock);
  ...
}

CompleteRequest is only ever called from DispatchRequests - which locks Hierarchy.NodesLock in its scope. Again, this is an SRW lock used recursively, I removed the CompleteRequest one to keep the wider lock and stay safer.

3. This last one is potentially a false positive. When launching Unreal Editor I get many errors pop up saying an SRW lock is initialized twice. It happens a little all over the place, and I’m struggling to get a good repro. What seems to be a concrete fix is to either:

- Initialize SRWLOCK.Ptr to nullptr in the class.

- Initialize FWindowsRWLock.Mutex to {0} (for something more localized and like SRWLOCK_INIT).

This seems to be happening around reuse on the stack, so I’m not sure if this issue is legit or a limitation of Application Verifier. SRW locks are simple and have no shutdown functionality - so it may just be that the verifier is unable to determine that the old lock is no longer in use, and that we are attempting to initialize a new lock (which just happens to be at an address previously initialized).

Anyway - I just wanted to point these out. Would be nice if we had official fixes for these so that people can use Application Verifier out of the box. Thanks,

Bram

Steps to Reproduce
Application Verifier is a Windows tool available here:

https://learn.microsoft.com/en\-us/windows\-hardware/drivers/devtest/application\-verifier

It detects common issues around memory, locks, etc. Simply booting the Editor with the verifier running will hit the issues below. The whole ‘Basics’ category should be enabled, but just in case - verify that Basics->SRWLock validation is enabled.

Hey Bram,

We’ve used Application Verifier occasionally, but we don’t have an automated CI job, so thank you for reporting these!

I’ll forward both cases to their teams so they can review them.

For the last one, I think it’s unlikely we’ll investigate further for the moment, unless we start establishing an automated setup with Application Verifier.

Thanks again!

Best,

Sebastian