ZDoom

Seems it's gone after the texture refactor.

Just asking. It's not my problem but our problem.
No crash here with KDIZD 1.2 and g4.4pre-381-g70d30feb4. RelWithDebInfo v141 64 bit. But actually there's another crash if i exit the selection box without launching the game.

drfrag wrote:What about reverting the old "fix"?

Short of prettying the code, the fix does not affect anything whatsoever and reverting it will not fix your problem.

I had no crashes with the IWADs, I had crashes with KDiZD. The IWADs do not seem to trigger the condition that causes the problem.

I've just tried with the iwads for now, 10 launches in a row and now another 10.
What about reverting the old "fix"?

I just had a crash with this code on my rework branch. But it wasn't mMaterial.mMaterial.tex that was bogus, but mMaterial.mMaterial itself.
On KDiZD Z1M1 I can reproduce it with almost 100% certainty after the initial wipe.
From the looks of it it tries to access the invalid material from the wipe texture. The problem looks to be PolyRenderState::Clear, being called from Set3DViewport which for unknown reason calls 'Apply'. But right after the wipe that's plain and simply an undefined operation because the currently set texture is no longer valid.

Okay.

I need that to get the code into Raze and have it 100% identical with GZDoom. For the transition I must ensure that I can compile both engines off the exact same backend code base. Once the transition is complete the #define can be removed again

Done, seems it's gone now.
BTW what is the HAVE_SOFTPOLY option on linux for? AFAIK it's the minimal compile unit and it runs on software so it's always available, precisely i have a HAVE_OPENGL option to compile only with softpoly.

Can you test this on the texture rework branch?

Yep seems that's the best course of action.

No matter how you slice it, an access violation for mMaterial.mMaterial->tex->shaderspeed can only be explained by two things: 1) access a pointer after deletion, 2) massive memory buffer overruns that messed up the pointer.

In any case, I'm in favor of waiting doing anything about it until graf's new branch gets merged in. There's no point in trying to do a workaround if the changes Graf did may have solved by the problem already, which it very well might. And even if it didn't, you'd have to do the fix twice then.

No idea of what's going on but i notice that when it crashes the screen is shrunk horizontally (a 16:9 window gets converted to a 4:3 window).
The same code is in the Vulkan backend in VkRenderState::ApplyStreamData() and it doesn't crash there:

Which pointer is left behind? Be aware that I changed the logic a lot here in my current work branch, so it might make sense to check the problem with that.

The problem isn't the texture class, but that FMaterialState::tex somehow leaves a deleted pointer behind. The OpenGL version doesn't crash from it because it only examines the field if mChanged is set to true, and then OpenGL itself doesn't care if you reference a deleted texture object.