[Closed] Random crash in softpoly

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Random crash in softpoly

Postby drfrag » Tue Apr 21, 2020 5:19 am

Since ???. Latest devbuild crashes (gzdoom-x64-g4.4pre-297-gc37dcc6eb). It's a random crash, it was rare and seems now it crashes more often i think it's not recent. I've copied all the info.
I've used Heretic but happens also with Doom 2. When you start a game before the weapon rises after the wipe sometimes it crashes. It's my master branch, it's the same code and right now i can't compile GZDoom (each project takes several GBs of disk space since VS is so bloated). Has anyone experienced this? I don't know what i can say i play @712x400 resolution, software light mode.

Code: Select allExpand view
    lzdoom.exe!PolyRenderState::Apply() Line 284   C++
    lzdoom.exe!PolyRenderState::Clear(int targets) Line 144   C++
    lzdoom.exe!HWDrawInfo::Set3DViewport(FRenderState & state) Line 639   C++
    lzdoom.exe!PolyFrameBuffer::RenderViewpoint(FRenderViewpoint & mainvp, AActor * camera, IntRect * bounds, float fov, float ratio, float fovratio, bool mainview, bool toscreen) Line 360   C++
>   lzdoom.exe!PolyFrameBuffer::RenderView(player_t * player) Line 323   C++
    [External Code]   
    [Inline Frame] lzdoom.exe!std::_Func_class<void>::operator()() Line 927   C++
    [Inline Frame] lzdoom.exe!D_Render(std::function<void __cdecl(void)>) Line 519   C++
    lzdoom.exe!D_Display() Line 927   C++
    lzdoom.exe!D_DoomLoop() Line 1192   C++
    lzdoom.exe!D_DoomMain_Internal() Line 3351   C++
    lzdoom.exe!D_DoomMain() Line 3366   C++
    lzdoom.exe!DoMain(HINSTANCE__ * hInstance) Line 963   C++
    lzdoom.exe!wWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * nothing, wchar_t * cmdline, int nCmdShow) Line 1291   C++

      firstFrame   3109   unsigned __int64
+      mMaterial   {mMaterial=0x00000210ded9b5a0 {mTextureLayers=Size = 0 mShaderIndex=134217777 mLeftOffset=276 ...} mClampMode=...}   FMaterialState
+      mMaterial.mMaterial   0x00000210ded9b5a0 {mTextureLayers=Size = 0 mShaderIndex=134217777 mLeftOffset=276 ...}   FMaterial *
+      mMaterial.mMaterial->tex   0x0000011a08000031 {Scale={X=??? Y=??? } SourceLump=??? id={...} ...}   FTexture *
+      mStreamData   {uObjectColor={r=1.00000000 g=1.00000000 b=1.00000000 ...} uObjectColor2={r=0.000000000 g=0.000000000 ...} ...}   StreamData
      mStreamData.timer   0.000000000   float
+      screen   0x00000210d6991060 {swdrawer=empty FrameDeleteList={Buffers={ size=0 } Images={ size=2 } } mLightBuffer=...}   DFrameBuffer * {PolyFrameBuffer}
      screen->FrameTime   3136   unsigned __int64
+      this   0x00000210d6a4ae40 {mMatrices={ModelMatrix={mMatrix=0x00000210d6a4b080 {1.00000000, 0.000000000, 0.000000000, ...} } ...} ...}   PolyRenderState *

      CT_Depth   CT_Depth (1)   EClearTarget
      targets   7   int
+      this   0x00000210d6a4ae40 {mMatrices={ModelMatrix={mMatrix=0x00000210d6a4b080 {1.00000000, 0.000000000, 0.000000000, ...} } ...} ...}   PolyRenderState *

      CT_Color   CT_Color (4)   EClearTarget
      CT_Depth   CT_Depth (1)   EClearTarget
      CT_Stencil   CT_Stencil (2)   EClearTarget
+      screen   0x00000210d6991060 {swdrawer=empty FrameDeleteList={Buffers={ size=0 } Images={ size=2 } } mLightBuffer=...}   DFrameBuffer * {PolyFrameBuffer}
+      screen->mSceneViewport   {left=0 top=0 width=712 ...}   IntRect
+      state   {mMatrices={ModelMatrix={mMatrix=0x00000210d6a4b080 {1.00000000, 0.000000000, 0.000000000, 0.000000000, ...} } ...} ...}   FRenderState & {PolyRenderState}
+      this   0x00000210deab3080 {drawlists=0x00000210deab3080 {{walls=Size = 0 flats=Size = 0 sprites=Size = 0 ...}, ...} ...}   HWDrawInfo *

+      di   0x00000210deab3080 {drawlists=0x00000210deab3080 {{walls=Size = 0 flats=Size = 0 sprites=Size = 0 ...}, ...} ...}   HWDrawInfo *
+      di->Viewpoint   {player=0x0000000000000000 <NULL> Pos={X=128.00000000000000 Y=-944.00000000000000 Z=65.000000000000000 } ...}   FRenderViewpoint
+      this   0x00000210d6991060 {swdrawer=empty FrameDeleteList={Buffers={ size=0 } Images={ size=2 } } mLightBuffer=...}   PolyFrameBuffer *

+      All   {...}   glcycle_t
+      player   0x00007ff7f9850990 {lzdoom.exe!player_t players[8]} {mo=0x00000210da658090 "HereticPlayer" playerstate=...}   player_t *
+      player->camera   "HereticPlayer"   TObjPtr<AActor *>
+      r_viewpoint   {player=0x0000000000000000 <NULL> Pos={X=128.00000000000000 Y=-944.00000000000000 Z=65.000000000000000 } ...}   FRenderViewpoint
+      r_viewpoint.FieldOfView   90.000000000000000   TAngle<double>
      r_viewpoint.FieldOfView.Degrees   90.000000000000000   double
+      this   0x00000210d6991060 {swdrawer=empty FrameDeleteList={Buffers={ size=0 } Images={ size=2 } } mLightBuffer=...}   PolyFrameBuffer *
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: Random crash in softpoly

Postby Rachael » Tue Apr 21, 2020 5:53 am

The ever-important question would obviously be, what mods are you loading?

Do you have any data you can give to help reproduce the issue?
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Random crash in softpoly

Postby drfrag » Tue Apr 21, 2020 6:00 am

None, it crashes with just the iwads. That's why i didn't mention it. I just start a new game and crashes, if it doesn't crash i quit and try again it's random.
I use maximum view size with HUD, that's something i didn't mention.
You do not have the required permissions to view the files attached to this post.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: Random crash in softpoly

Postby drfrag » Tue Apr 21, 2020 6:18 am

I notice that for mMaterial.mMaterial->tex->shaderspeed says <Unable to read memory>.
VS says it's at line 144 in poly_renderstate.cpp but clearly entered Apply() (mNeedApply was true and was set to false there), is it really that bad? I'm using VS 2017 BTW.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: Random crash in softpoly

Postby Rachael » Tue Apr 21, 2020 7:03 am

Easily reproduced with the ini you gave. I'll try and give a look at this later when I am not on a time constraint.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Random crash in softpoly

Postby Rachael » Tue Apr 21, 2020 7:30 am

Okay, it looks like mMaterial.mMaterial->tex pointer is not properly cleared, there's a null check here but an access violation occurs when attempting to read it, which likely means that the space was previously allocated but then released, but the pointer was not cleared in the process.

Unfortunately, tracking this down is a huuuuuge pain in the ass.

There may be other causes to this issue, but I am not aware of them right now and this seems to be the most likely case. (actually, it could also be that the pointer is not properly initialized when an instance is created - that should be an easy fix if this is the case)

In GZDoom it crashes in poly_renderstate.cpp line 284 in attempting to read mMaterial.mMaterial->tex after the nullptr check was okayed.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Random crash in softpoly

Postby Rachael » Tue Apr 21, 2020 7:42 am

User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Random crash in softpoly

Postby drfrag » Tue Apr 21, 2020 11:52 am

Looks good.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: Random crash in softpoly

Postby drfrag » Fri Apr 24, 2020 3:04 am

Sorry for the delay but i've retested this and it still crashes. Same stack.
Last edited by drfrag on Fri Apr 24, 2020 5:22 am, edited 1 time in total.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: Random crash in softpoly

Postby Rachael » Fri Apr 24, 2020 3:12 am

Well I do remember at some point that someone said pointers are always initialized to null, anyhow. The problem went away for me, after I forced it, so I figured it was a compiler error that was letting them go non-null like that. Guess I might've been wrong.

So in order to fix this, it seems one must search the entire code base for this pointer's usage, and ensure that any deallocation calls are appended with a null assignment afterward. That might be what will fix this. Best way to handle it is to create a destructor that does it if one does not exist already and make sure all the deallocation calls pass to the destructor instead of handling it directly.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Random crash in softpoly

Postby dpJudas » Fri Apr 24, 2020 3:36 am

The error here is most likely that you can't determine if a material is available by looking at the pointer at all, but must do the check in whatever convoluted way the OpenGL backend happens to be doing it.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Random crash in softpoly

Postby Graf Zahl » Fri Apr 24, 2020 4:08 am

For a texture the check must be "tex != nullptr && tex->isValid()". Textures of type Null do not exist, they just occupy slots in the texture list but do not represent anything valid, but of course pointers to them can be held. If you try to do stuff with such a texture, bad things will happen.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Random crash in softpoly

Postby dpJudas » Fri Apr 24, 2020 4:27 am

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.
dpJudas
 
 
 
Joined: 28 May 2016

Re: Random crash in softpoly

Postby Graf Zahl » Fri Apr 24, 2020 4:45 am

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Random crash in softpoly

Postby drfrag » Fri Apr 24, 2020 5:07 am

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:
Code: Select allExpand view
   if (mMaterial.mMaterial && mMaterial.mMaterial->tex)
      mStreamData.timer = static_cast<float>((double)(screen->FrameTime - firstFrame) * (double)mMaterial.mMaterial->tex->shaderspeed / 1000.);
   else
      mStreamData.timer = 0.0f;
Last edited by drfrag on Fri Apr 24, 2020 5:29 am, edited 2 times in total.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Next

Return to Closed Bugs

Who is online

Users browsing this forum: No registered users and 0 guests