Trying to use ASAN on our end I was immediately faced with two errors caught by the tool.
This happened in Win64 Development config, compiled with clang 18.1.3 and linked with link.exe
I am adding their logs in the attached file.
1: stack use after scope
In `USlateScreenReaderEngineSubsystem::Initialize` the code takes a const reference to a TSharedRef<GenericApplication> that is obtained via an anonymous temporary object (result of `ToSharedRef`).
It is then used just after to initialize other stuff, but the referenced TSharedRef has already died.
I believe the correct fix is to modify `IScreenReaderBuilder::FArgs` to store a plain TSharedRef instead of a reference. I did it locally and it fixed the error, however I did not try to use this plugin.
2: use after free
When closing our test game, an instance of `FSceneViewport` is apparently used after being freed.
Judging by the callstacks it looks like a vanilla engine issue but I can’t guarantee our code has no influence on it.
1: Your fix seems indeed correct for the ScreenReader issue. I’ll test and submit it.
2: I wasn’t able to reproduce this one, and I don’t see how this could happen, unless ~FSceneViewport() is not called propertly at destruction time? This code does unregister a delegate (FSlateApplication::Get().GetRenderer()->OnSlateWindowDestroyed().RemoveAll(this);), and therefore, the use after free you got should not occurs, as FSceneViewport::OnWindowBackBufferResourceDestroyed should not be called.
Could you check if the FSceneViewport destruction process is correctly executed on your side?
While stepping in FSceneViewport destructor, where you able to confirm that FSlateApplication::Get().GetRenderer()->OnSlateWindowDestroyed().RemoveAll(this); was called properly?
It would be interesting also to know which FSceneViewport (as there can be many) stays registered and if it has anything particular? Unless the same issue occurs on all FSceneViewports?
