Calling "path.flattening()" on some DXF files crashes the Python interpreter

[angelo-aldrovandi-hydro-com]

Making a path out of a POLYLINE and calling path.flattening() crashes the Python interpreter with 0xC00000FD with some DXF files (which look completely normal files).

This is a code snippet you might use:

---

doc, _ = ezdxf.recover.readfile(filename)
entities = list(doc.modelspace().query('POLYLINE LWPOLYLINE'))
for entity in entities:
path = ezdxf.render.path.make_path(entity)
# This crashes Python interpreter with 0xC00000FD
vertices = list(path.flattening(tolerance))
# render/path.py:671 -> return Bezier4P((s, c1, c2, e)).flattening(distance, segments)

---

I'm Python 3.8.7 64bit on Windows 10 and ezdxf==0.15.2 (but I also tried 0.17.2, current stable version at the time of writing)

Thanks in advance for your support 👍

Crash.zip

[mozman]

This is a know issue if handling with big coordinates. The POLYLINE entity has an elevation of 1.391912e+19.
The bezier interpolation algorithm returns points with floating point imprecision like z=1.3919120000000002e+19, which looks not much but 1.391912e+19 - 1.3919120000000002e+19 = -2048.0. I have added an emergency exit for suddenly very large distances, but this max value is currently 1e12 which does not cover this example.

I have no idea how to solve this issue. The best solution is to keep coordinates of entities in the range of planet earth ;-).

I will try to avoid the stack overflow in the c-extension.

[mozman]

A fix could be to translate this entities to the xy-plane:

from ezdxf import path
...

for e in doc.modelspace().query('POLYLINE LWPOLYLINE'):
    z = e.dxf.elevation.z
    if z > 1e12:
        e.translate(0, 0, -z)
    p = path.make_path(e)
    vertices = list(p.flattening(tolerance))

[angelo-aldrovandi-hydro-com]

Thanks for your reply, the workaround is working indeed 👍 I will also implement some scale-check on loading, I guess it's on the z-plane only, because drawings must be otherwise properly scaled. Thanks again!

[mozman]

The latest implementation should fix the large coordinate issue for Bezier4P and Bezier3P curves (representation of arcs in paths) by internally translating the curve to the origin of the coordinate system, start point of the curve is (0, 0, 0).

The only unresolved problem are curves where the distances between control points are very large, but this is an inherent floating point problem.