Difference between revisions of "Starting on a vertex between visplanes causes illegal memory access"

From DoomWiki.org

[unchecked revision][checked revision]
(Cause)
(wikilinks)
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
Under certain circumstances, if a player start is placed on a vertex between visplanes, Vanilla Doom will crash due to an illegal memory access.
+
Under certain circumstances, if a [[player]] start is placed on a [[vertex]] between [[visplane]]s, [[vanilla Doom]] will [[Venetian blind crash|crash]] due to an {{wp|Page fault|illegal memory access}}.
  
 
== Details ==
 
== Details ==
  
If the player starts on a vertex on a two-sided line, and the sectors on either side can each be rendered as different visplanes (e.g. differing heights or light levels), Vanilla Doom performs an illegal memory access. Depending on the environment, this may throw an exception 0Eh (page fault) in DOS/4GW.
+
If the player starts on a vertex on a two-sided [[linedef|line]], and the [[sector]]s on either [[sidedef|side]] can each be rendered as different visplanes (e.g. differing heights or light levels), vanilla Doom performs an illegal memory access. Depending on the environment, this may throw an exception 0Eh (page fault) in {{wp|DOS/4GW}}.
  
 
== Cause ==
 
== Cause ==
  
The cause is reportedly due to a bug in the R_PointToDist function in r_segs.c, but the exact nature has yet to be verified.
+
The cause is reportedly due to a bug in the R_PointToDist function in [[Doom source code files|r_segs.c]], but the exact nature has yet to be verified.
  
James Haley's explanation:
+
Possible explanation by [[James Haley (Quasar)|Quasar]]:<ref>{{dwforumsp|1140884|Post by Quasar on BTSX thread}}</ref>
 +
:''All I can figure out is that vanilla DOOM must install a handler that causes integer division by zero exceptions to be effectively ignored. Unfortunately it apparently leaves the value in edx:eax undefined after the idiv instruction, which then leads to out-of-bounds indexes into tantoangle and/or finesine. What happens from there's anybody's guess. You say visplanes seem to influence it; I cannot rule out or confirm that myself :)''
  
<blockquote>"All I can figure out is that vanilla DOOM must install a handler that causes integer division by zero exceptions to be effectively ignored. Unfortunately it apparently leaves the value in edx:eax undefined after the idiv instruction, which then leads to out-of-bounds indexes into tantoangle and/or finesine. What happens from there's anybody's guess. You say visplanes seem to influence it; I cannot rule out or confirm that myself :)
+
:''BTW this was independently fixed by [[Jim Flynn]] in [[BOOM]] 2.02 and [[Lee Killough]] in [[MBF]], in slightly different ways, so that R_PointToDist returns 0 if you are on the [[seg]]'s v1 vertex instead of dividing by zero. BOOM once again proves 0/0 == 0 apparently.''
  
BTW this was independently fixed by Jim Flynn in BOOM 2.02 and Lee Killough in MBF, in slightly different ways, so that R_PointToDist returns 0 if you are on the seg's v1 vertex instead of dividing by zero. BOOM once again proves 0/0 == 0 apparently"</blockquote>
+
Boom 2.02 and MBF fix this bug.
 
 
Boom 2.02 and MBF fixes this bug.
 
  
 
== Sources ==
 
== Sources ==
[http://www.doomworld.com/vb/post/1140791 Post on BTSX thread containing explanation]
+
*{{dwforumsp|1140791|Post by The Green Herring on BTSX thread}}
[http://www.doomworld.com/vb/post/1140884 James Haley's explanation]
 
  
 +
== References ==
 +
<references/>
  
 
[[Category:Errors and bugs]]
 
[[Category:Errors and bugs]]

Latest revision as of 14:37, 29 January 2013

Under certain circumstances, if a player start is placed on a vertex between visplanes, vanilla Doom will crash due to an illegal memory access.

Details[edit]

If the player starts on a vertex on a two-sided line, and the sectors on either side can each be rendered as different visplanes (e.g. differing heights or light levels), vanilla Doom performs an illegal memory access. Depending on the environment, this may throw an exception 0Eh (page fault) in DOS/4GW.

Cause[edit]

The cause is reportedly due to a bug in the R_PointToDist function in r_segs.c, but the exact nature has yet to be verified.

Possible explanation by Quasar:[1]

All I can figure out is that vanilla DOOM must install a handler that causes integer division by zero exceptions to be effectively ignored. Unfortunately it apparently leaves the value in edx:eax undefined after the idiv instruction, which then leads to out-of-bounds indexes into tantoangle and/or finesine. What happens from there's anybody's guess. You say visplanes seem to influence it; I cannot rule out or confirm that myself :)
BTW this was independently fixed by Jim Flynn in BOOM 2.02 and Lee Killough in MBF, in slightly different ways, so that R_PointToDist returns 0 if you are on the seg's v1 vertex instead of dividing by zero. BOOM once again proves 0/0 == 0 apparently.

Boom 2.02 and MBF fix this bug.

Sources[edit]

References[edit]

  1. Post by Quasar on BTSX thread