Map Crashing

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
User avatar
Quantum_Dranger
Posts: 18
Joined: Fri Jul 22, 2016 10:29 am

Map Crashing

Post by Quantum_Dranger »

http://www.mediafire.com/file/pzf1u4xge ... plane2.wad

Hey,
When I try to run this in gzdoom, it crashes on start. Could someone let me know what is wrong and how to fix it? I have a feeling it might be the nodes but I'm not sure and I don't know how I would fix that.
User avatar
Kappes Buur
 
 
Posts: 4114
Joined: Thu Jul 17, 2003 12:19 am
Graphics Processor: nVidia (Legacy GZDoom)
Location: British Columbia, Canada
Contact:

Re: Map Crashing

Post by Kappes Buur »

Your map is too large,
Spoiler:
scale it down to perhaps 95% or smaller in both directions, x and y.
Spoiler:
Tip:
To build your map in the corner of the editable area is not advisable, build from the center outwards.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: Map Crashing

Post by _mental_ »

It's an overflow in internal node builder indeed. However GZDoom shouldn't crash in such case.
The topic needs to be moved to Bugs subforum. The given map can be loaded in PrBoom+ by the way.
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: Map Crashing

Post by Rachael »

_mental_ wrote:The topic needs to be moved to Bugs subforum.
This can be accomplished by reporting the leading post of the topic in question. The "other" reason allows you to communicate any message to the moderator handling the report - be it positive or negative or neither.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Map Crashing

Post by Graf Zahl »

I don't think this can be fixed without an entire rewrite of the node builder to use higher precision values.

The map is built right to the negative edge of the coordinate space and the fixed point math cannot deal with that because it got no headroom left to work with - and somehow those -32768 x-coordinates end up as a value on the other edge of the value spectrum.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: Map Crashing

Post by _mental_ »

IMHO the current limits are enough to create virtually any imaginable map.
At the same time it will be nice to add some checks to prevent this crash.
The question is what are those min/max coordinates exactly?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Map Crashing

Post by Graf Zahl »

What happened here is that the map put a vertex right on the outermost edge of the coordinate system at -32768. This caused problems because there is no more room for adding a safety margin. The node builder is trying to do that and overflows.

With -32767 the thing should still work.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: Map Crashing

Post by _mental_ »

Even if the map will be fixed to do not use edge case coordinates by replacing -32768 with -32767, it's still trigger assertion failure here.
FVertexMap::BlocksTall is 133 ans so BlocksTall * BLOCK_SIZE - 1 is below zero leading to negative MaxY.
Nodes seem to be build correctly with that assertion removed. Should BlocksWide / BlocksTall be limited to 128?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Map Crashing

Post by Graf Zahl »

I'd just rewrite the VertexMap to use 48.16 fixed point numbers instead to get rid of the overflows. I think any other approach may compromise robustness.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: Map Crashing

Post by _mental_ »

I was thinking about the same, just without the exact precision for fixed point numbers. I will try with 48.16 which seems reasonable.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: Map Crashing

Post by _mental_ »

Pull request. The given map works fine out of the box.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Map Crashing

Post by Graf Zahl »

What's the point of this:

Code: Select all

+			fixed64_t vx = Vertices[seg->v1].x;
+			fixed64_t vy = Vertices[seg->v1].y;
+			vx += fixed64_t(frac * double(Vertices[seg->v2].x - vx));
+			vy += fixed64_t(frac * double(Vertices[seg->v2].y - vy));
+			newvert.x = fixed_t(vx);
+			newvert.y = fixed_t(vy);
In the end it just throws away the added bits without ever making use of them. Is there any reason this is in 64 bit?
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: Map Crashing

Post by _mental_ »

Yes, because with 32-bit fixed_t values are silently overflow/wrap. This was the cause of assertion failures.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Map Crashing

Post by Graf Zahl »

I think for that it would have been sufficient to change the 'double' cast to only cover the first part of the subtraction that's currently being performed as integer. Once the subtraction is done in floating point such overflows should be gone.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: Map Crashing

Post by _mental_ »

Yes, this works too. I force pushed the change.
Post Reply

Return to “Closed Bugs [GZDoom]”