ZDoom

Linedefs 1533, 1535, 1538, 1541 (relatively to portals.CRASH.wad)
Highlighted with yellow, if I remove these sectors it stops blocking
[img]https://i.imgur.com/jlNAtBT.png[/img]

Also, partially related: GZDoom ate ~48px of upper portal sector in the reflection: https://i.imgur.com/7JY08hP.png
Might be related to the fact that portal plane's Z is -56px.

Fixed the crash, but to analyze the glitch this map is too complex. Can you try reducing detail a bit while retaining the glitch? With this many linedefs in the game it is very hard to find out which one causes the renderer to think that it cannot see all parts of the portal.

Hm. You seem to have found the one situation here where the multithreading in the renderer appears to get into synchronization problems. Both the main thread and the worker can modify the scene's portal state and occasionally stomp onto each other's data, and that's the random crash here.

When I switch off the multithreading the crash disappears, but not the glitch. It does look a bit different, though.

 	725f3332()	Unknown
 	[Frames below may be incorrect and/or missing]	
>	gzdoom.exe!FPortalSceneState::EndFrame(HWDrawInfo * di, FRenderState & state) Line 101	C++
 	gzdoom.exe!OpenGLRenderer::FGLRenderer::DrawScene(HWDrawInfo * di, int drawmode) Line 141	C++
 	[External Code]	
 	gzdoom.exe!HWDrawInfo::ProcessScene(bool toscreen, const std::function<void __cdecl(HWDrawInfo *,int)> & drawScene) Line 655	C++
 	gzdoom.exe!OpenGLRenderer::FGLRenderer::RenderViewpoint(FRenderViewpoint & mainvp, AActor * camera, IntRect * bounds, float fov, float ratio, float fovratio, bool mainview, bool toscreen) Line 190	C++
 	gzdoom.exe!OpenGLRenderer::FGLRenderer::RenderView(player_t * player) Line 276	C++
 	gzdoom.exe!D_Display() Line 758	C++
 	gzdoom.exe!D_DoomLoop() Line 1008	C++
 	gzdoom.exe!D_DoomMain() Line 2681	C++
 	gzdoom.exe!DoMain(HINSTANCE__ * hInstance) Line 1077	C++
 	gzdoom.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * nothing, char * cmdline, int nCmdShow) Line 1349	C++
 	[External Code]	

Stack trace is against Git revision c92e6b03ac461ac16c13412ae414332145e60081.
The "725f3332()" is apparently virtual delete in HWPortal.
[code] 725f3332() Unknown
[Frames below may be incorrect and/or missing]
> gzdoom.exe!FPortalSceneState::EndFrame(HWDrawInfo * di, FRenderState & state) Line 101 C++
gzdoom.exe!OpenGLRenderer::FGLRenderer::DrawScene(HWDrawInfo * di, int drawmode) Line 141 C++
[External Code]
gzdoom.exe!HWDrawInfo::ProcessScene(bool toscreen, const std::function<void __cdecl(HWDrawInfo *,int)> & drawScene) Line 655 C++
gzdoom.exe!OpenGLRenderer::FGLRenderer::RenderViewpoint(FRenderViewpoint & mainvp, AActor * camera, IntRect * bounds, float fov, float ratio, float fovratio, bool mainview, bool toscreen) Line 190 C++
gzdoom.exe!OpenGLRenderer::FGLRenderer::RenderView(player_t * player) Line 276 C++
gzdoom.exe!D_Display() Line 758 C++
gzdoom.exe!D_DoomLoop() Line 1008 C++
gzdoom.exe!D_DoomMain() Line 2681 C++
gzdoom.exe!DoMain(HINSTANCE__ * hInstance) Line 1077 C++
gzdoom.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * nothing, char * cmdline, int nCmdShow) Line 1349 C++
[External Code]
[/code]

Steps to reproduce:
1. Make sure you have vid_rendermode=4
2. Use the map attached (IWAD=doom2.wad). The reflective floors are 1.0 reflective on purpose — makes it easier to spot the issue.
3. Position yourself at roughly (-3289, 488, 32)
4. Make sure you see this: https://i.imgur.com/2K8e5sI.png (this is on it's own a problem, but not related and not visible in production map so w/e)
5. Move around for a bit, turn camera around. It will crash at some point



You can try the attached demo. For me it crashes reliably (and differently every time!)