Scopelock issue in UGCObjectReferencer::AddObject

Development Platform & Builds
, ,
1

Just a heads up that we discovered in co-ordination with Havok an issue in UGCObjectReferencer::AddObject in 5.6 the code was adjusted and the Scopelock no longer covers the OnGCObjectAdded.Broadcast making that call no longer thread-safe. We re-introduced a scopelock for the Broadcast call but wanted to highlight it for review.

This was only an issue for Editor and seemed to occur when the game was calling FGCObject in a ParallelFor

2

Steps to Reproduce
Just a heads up that we discovered in co-ordination with Havok an issue in UGCObjectReferencer::AddObject in 5.6 the code was adjusted and the Scopelock no longer covers the OnGCObjectAdded.Broadcast making that call no longer thread-safe. We re-introduced a scopelock for the Broadcast call but wanted to highlight it for review.

This was only an issue for Editor and seemed to occur when the game was calling FGCObject in a ParallelFor

3

Hey Matthew, thanks for posting.

Here’s the commit that moved the OnGCObjectAdded.Broadcast(Object) out of the lock scope,

https://github.com/EpicGames/UnrealEngine/commit/dee0358cf4905719b937fdee804a4a76af43081c\#diff\-1625ad4aae8ea73e946c45fad525bfdba7bf854832dca0b5328dd4e63eebde1c,

which made it unsafe to create FGCObject in a multithreaded fashion.

We wonder if that’s an inadvertent change and if it will be put back into a lock scope in a future release?

4

Hi,

Thanks for reporting, this is likely a bug and your fix looks legit. I have started a discussion with the developer and I’ll let you know how this turns out.

Regards,

Patrick

5

FYI: This was an oversight, I created a JIRA for the auto RTFM team (For internal ref: SOL-8430).

Regards,

Patrick