Crash (Thread Split)
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: Crash (Thread Split)
Thanks for testing again. Just to rule out possibilities, if you launch Doom 2 at 800x600 with no additional addons, does it still crash?
@Eruanna: okay, so we have two haswell that run fine (yours and mine), a nehalem that runs fine, and a ivybridge that is crashing. I wonder that those two Celerons would be classified as.
@Eruanna: okay, so we have two haswell that run fine (yours and mine), a nehalem that runs fine, and a ivybridge that is crashing. I wonder that those two Celerons would be classified as.
- Tiger
- Developer
- Posts: 863
- Joined: Thu Feb 25, 2010 3:44
- Location: United States
- Contact:
Re: Crash (Thread Split)
I've played through MAP01 - MAP14 of the Doom2 game, though honestly - I forgot to flip to the SuperVGA standard until maybe MAP12, but no crashes to report.dpJudas wrote:Thanks for testing again. Just to rule out possibilities, if you launch Doom 2 at 800x600 with no additional addons, does it still crash?
Nicholas 'Tiger' Gautier
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: Crash (Thread Split)
Excellent. Thanks for testing.
- Tiger
- Developer
- Posts: 863
- Joined: Thu Feb 25, 2010 3:44
- Location: United States
- Contact:
Re: Crash (Thread Split)
I've decided to make a demonstration video, hopefully this helps? Also, there is some skips with the video, I am experimenting with the encoder. Despite the skipping, it should be doable atleast for demonstration purposes.
Nicholas 'Tiger' Gautier
- Rachael
- Developer
- Posts: 3646
- Joined: Sat May 13, 2006 10:30
Re: Crash (Thread Split)
Opened the report again - sorry. I thought you fixed it.
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: Crash (Thread Split)
It seems the original "launching doom 2 crashes" drawer problem is gone, or at least this particular issue doesn't seem to be related to it.
The crash on the video seems to be a general rendering bug. Would need to test if it also happens in ZDoom or not (any recent zdoom build will do). General rendering crashes unfortunately often appear as drawer errors due to the way rendering is done.
The crash on the video seems to be a general rendering bug. Would need to test if it also happens in ZDoom or not (any recent zdoom build will do). General rendering crashes unfortunately often appear as drawer errors due to the way rendering is done.
- Tiger
- Developer
- Posts: 863
- Joined: Thu Feb 25, 2010 3:44
- Location: United States
- Contact:
Re: Crash (Thread Split)
I quickly grabbed the ZDoom (x86_64) dev build: 2.9pre-1447-g4b956a2, it seems that I am unable to reproduce the crash that I would get with QZDoom.
Nicholas 'Tiger' Gautier
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: Crash (Thread Split)
Rats! Okay, I guess there must be some problem with the outdoor rendering of that mod you're playing, just as you said yourself.
- Tiger
- Developer
- Posts: 863
- Joined: Thu Feb 25, 2010 3:44
- Location: United States
- Contact:
Re: Crash (Thread Split)
By chance, was this issue related to the 'Random crash' that was reported by Nash - which making this report resolved, or is it different in my case? In addition, should I retest using the latest stable or dev. build?
Nicholas 'Tiger' Gautier
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: Crash (Thread Split)
It could be related. It is worth a try I guess. You don't have to torture yourself with the Doom 2 part tho - that original issue seem to have been resolved.
Edit: best one to test with would be the 1.0.0 release Eruanna just did.
Edit: best one to test with would be the 1.0.0 release Eruanna just did.
- Tiger
- Developer
- Posts: 863
- Joined: Thu Feb 25, 2010 3:44
- Location: United States
- Contact:
Re: Crash (Thread Split)
I'll perform another test later today, and I'll use the stable build as directed.
Nicholas 'Tiger' Gautier
- Tiger
- Developer
- Posts: 863
- Joined: Thu Feb 25, 2010 3:44
- Location: United States
- Contact:
Re: Crash (Thread Split)
I have found something strange with this build. I am able to capture the messages that would previously crash-out the client, but it looks like I stumbled onto something new.
Code: Select all
<------------------------------->
amisery - Abandoned Misery [Pretty]
game saved. (C:\Users\Nicholas\AppData\Roaming\GZDoom\Saves/auto0.zds)
Picked up a box of bullets.
You got the super shotgun!
]noclip2
No Clipping Mode 2 ON
]noclip2
No Clipping Mode OFF
Read access violation: DrawColumnRt
dest_y = 411, count = 8, flags = 1, iscale = 68841 (1.050430), texturefrac = 0 (0.000000)
You got the railgun!
You got the super shotgun!
Picked up an armor bonus.
Picked up an armor bonus.
Picked up an armor bonus.
You got the grenade launcher!
Picked up a box of rockets.
You got the rocket launcher!
Picked up a box of rockets.
Picked up the armor.
Picked up a box of shotgun shells.
**** DIED WITH FATAL ERROR:
Write access violation: DrawColumnHoriz
Nicholas 'Tiger' Gautier
- Rachael
- Developer
- Posts: 3646
- Joined: Sat May 13, 2006 10:30
Re: Crash (Thread Split)
Well.... it's still Carmack's renderer. What can I say?
Those lines are, in fact, a read access violation in progress. QZDoom catches those, now. But it will still crash out on the write access violations (as far as I know) since there is currently no way to protect the code when stray pointers occur.
Those lines are, in fact, a read access violation in progress. QZDoom catches those, now. But it will still crash out on the write access violations (as far as I know) since there is currently no way to protect the code when stray pointers occur.
- Tiger
- Developer
- Posts: 863
- Joined: Thu Feb 25, 2010 3:44
- Location: United States
- Contact:
Re: Crash (Thread Split)
Its time to get John Carmack back on this engine and have him fix it, with the most extreme measures!Eruanna wrote:Well.... it's still Carmack's renderer. What can I say?
I don't know how the software renderer works - under the hood, but why does this happen and how? What the potential reason for this happening?Eruanna wrote:Those lines are, in fact, a read access violation in progress. QZDoom catches those, now. But it will still crash out on the write access violations (as far as I know) since there is currently no way to protect the code when stray pointers occur.
Nicholas 'Tiger' Gautier
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: Crash (Thread Split)
If I'm to guess right now, the write access violation you get is probably the same cause as in Write access violation: DrawColumnHoriz reported by XxMiltenXx. I'm not sure of the cause here yet.
The read access violation is most likely due to the same thing as reported by Enjay and Abba Zabba. The good news about the read access violation is that Abba Zabba managed to capture a screenshot where it managed to sample those out-of-bounds textures without crashing (the vertical black lines) on imps. That means I'm pretty sure it's one of two lines in R_DrawVisSprite that causes the crash:
Now I just need to figure out which one and why.
By the way, the general rendering anomalies you see (i.e. voxels disappearing and such) are most likely zdoom issues.
The 'read access violation' means that it tried to read out of bounds of a texture. For example, if the texture is 128x128 and it tries to read pixel (129,1) it might sometimes get away with it depending on what is in memory next to the texture. The out of bounds happens due to broken calculations in the software renderer, mostly due to rounding issues and inaccurate math that Carmack only got away with doing because it was all fixed point. When Randi changed this to floats she kind of opened Pandora's box, but luckily there aren't that many places left that has to be fixed.
In most cases, the 'write access violation' means that it tried to write outside the screen. Once again some broken math is the cause - typically in this case due to overflows that didn't happen before things were converted to floats.
The read access violation is most likely due to the same thing as reported by Enjay and Abba Zabba. The good news about the read access violation is that Abba Zabba managed to capture a screenshot where it managed to sample those out-of-bounds textures without crashing (the vertical black lines) on imps. That means I'm pretty sure it's one of two lines in R_DrawVisSprite that causes the crash:
Code: Select all
iscale = (fixed_t)(tex->GetWidth() / (dtx2 - dtx1) * FRACUNIT);
vis->startfrac += (fixed_t)(vis->xiscale * (vis->x1 - centerx - dtx1 + 0.5 * thingxscalemul));
By the way, the general rendering anomalies you see (i.e. voxels disappearing and such) are most likely zdoom issues.
Not sure if you're a developer or not, hopefully this isn't too technical.Tiger wrote:I don't know how the software renderer works - under the hood, but why does this happen and how? What the potential reason for this happening?
The 'read access violation' means that it tried to read out of bounds of a texture. For example, if the texture is 128x128 and it tries to read pixel (129,1) it might sometimes get away with it depending on what is in memory next to the texture. The out of bounds happens due to broken calculations in the software renderer, mostly due to rounding issues and inaccurate math that Carmack only got away with doing because it was all fixed point. When Randi changed this to floats she kind of opened Pandora's box, but luckily there aren't that many places left that has to be fixed.
In most cases, the 'write access violation' means that it tried to write outside the screen. Once again some broken math is the cause - typically in this case due to overflows that didn't happen before things were converted to floats.