crashes python when using buggy geometry with 'p' flag #4
Comments
|
Can you provide a complete code sample that causes the crash? |
|
Sure, I've updated the original post accordingly. I believe that I've tried all of the other flags and this is the only flag that causes the crash. At one point, it threw this error, which appears to be from the underlying C triangles package: Here is the first part of the system's error report that I get when the crash occurs: |
|
I cannot duplicate this crash on Linux. In fact on my machine I get this output for poly_triangulation: This appears to be affecting MacOSX only. |
|
OK, thanks for looking. Really handy package by the way. |
|
Somewhat related to the above post (where a duplicate vertex crashes python on a mac) I've also found that if an interior poly shares a point with an exterior point, then a crash likewise ensues. (Whereas it would be nice if it surfaced as an error instead of crashing python.) At the moment I am pre-processing the geometries to catch these duplicates, then the crashes can be avoided.
from triangle import triangulate
geom = {
'segments': [
[0, 1],
[1, 2],
[2, 3],
[3, 0],
[4, 5],
[5, 6],
[6, 7]
],
'vertices': [
[0, 0],
[10, 0],
[10, 10],
[0, 10],
[0, 10],
[5, 1],
[5, 9]
],
'holes': [[4, 8]]
}
poly_triangulation = triangulate(geom, opts='p')
|
|
This happens for me on linux, too. |
|
On my machine (Xenial, Python 2.7.12) this seems to only happen if I from triangle import triangulate
#import multiprocessing # uncomment to cause crash
geom = {'segments': [ [0, 1], [1, 2], [2, 3], [3, 0], [4, 5], [5, 6], [6, 7] ],
'vertices': [ [0, 0], [10, 0], [10, 10], [0, 10], [0, 10], [5, 1], [5, 9] ],
'holes': [[4, 8]]}
poly_triangulation = triangulate(geom, opts='pVVV') With the gdb's stack trace is: The only thing in the valgrind log that looks relevant is: Trying to dump any variables that look potentially relevant at the time of the crash, and I get: But there's not anything noticeably different about the results with and without the |
|
@drmoose Can you try with the last version in the repository, and see if this crash still happens? |
|
Still present as of 071b444 |
|
Another example crash: Note that it is easy to avoid this crash by tweaking the coordinates in any slightest way. Catching the exception provides an easy workaround for this ugly computational geometry situation. |
|
I'm seeing a related issue. Its taken a while to track down a problematic polygon, but I've got one here that pretty reliably crashes. The weird thing is that it doesn't always crash. Running this directly on the command line ie. from polygon import path
results = triangulate(path, 'pzjqQn')@addam what do you mean this is easy to avoid? I can't catch any errors, as the program fully segfaults. Also, what do you mean by change the coordinates? Is there a specific type of change you are making? |
|
The problem in my case is numerical precision. If it was possible to catch the error, I could just add 0.0001 to any of the coordinates and everything would go well. It is even enough to change the order of edges, such as |
|
I looked into the crashes a while back, and I think the problem may be in the underlying triangle library, and not in the wrapper code, unless I am violating some assumption when calling into the underlying library. I am not really familiar with the details of how the C library works, so I am afraid I will not be of much help if it is the former. If any of you can fix this crash feel free to submit a pull request. |
|
@drufat, you are right: the crashes that I found (and there are many besides the one I posted) can be reproduced in plain Triangle program. I don't expect anybody to fix the error. What I'd like to see is a Python exception raised when the C code crashes. That way, it is possible to modify the input data or (at least) produce a meaningful error log. |
|
Since this is a memory error, I do not think there is a graceful way to recover from it in python.
Perhaps if we identify the pattern that causes it, we can create a guard in python that when the pattern is present raises an exception, and does not call the C code. That's the only workaround I can think of without touching the underlying C code.
Of course the best solution would be to fix the C code.
…On May 31, 2020 5:57:21 PM PDT, Jesse Vander Does ***@***.***> wrote:
@drufat I would second @addam's point about exception handling. I'm not
familiar with the wrapper, but avoiding the segfault would be a big
win.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#4 (comment)
|
|
Gotcha, makes sense. |
|
I may be late for the party, but it may be relevant for future searches. I was trying to make the triangulation automatic for my code so that it would get the lines, detect holes and concavities if there were any, and then triangulate using the I spent some time trying to understand why sometimes the code would just stop, no error raised, no warning, nothing. Then I realised that every time the simulation crashed, some of the points used to define holes were located outside the convex hull of the geometry. It wasn't definitive, though, since some of the times that it worked those points could also be there, even with convex geometries whitout any hole at all. But since I constrained the hole points to be inside the CH this problem didn't happen again. Anywho, it would be good to keep this in mind for stability fixes. Cheers! |
|
@drufat in my case, having repeated vertices in the input very often crashes the program, and based on my hopping around the internet this is indeed expected when vertices are repeated. (I apologise that I can't find the correct tab.) I've managed to correctly preprocess my data to remove repeated vertices, but as to what if len(np.unique(tri['vertices'], axis=0)) < len(tri['vertices']) and 'p' in opts:
raise ValueError('vertices cannot be repeated with option "p"')If performance is a concern, one could use create a flag like If this is acceptable to you @drufat I'd be happy to submit a PR... |
Ah, it was the link in this comment in #70. |
|
Yes, I found that duplicating vertices causes the program to crash. It bothered me for a long time |
I've found that buggy geometry processed with the 'p' flag will crash Python. I've tested on two systems, both Mac.
This reproduces the behaviour for me. Note the repeated vertex at index 4:
Would be nice if there were a way to throw an exception prior to Python itself crashing.
The text was updated successfully, but these errors were encountered: