Crashes (test program and Windows)

[gorza47]

Hi,

1. Thank you very much for this project, it is very fast/good!

2. But I discovered some serious crashes/problems ... which crashed my Windows 11!
   It can be reproduced with a special input TXT file (points which are already relaxed and saved).

The problem happens (at least) in "jcv_boxshape_fillgaps", maybe in some other places too.

Crash description: the test program eats (rapidly) my whole system memory (32 GB) ... Win11 goes down (dark screen) and needs a hard reset.

Test program compiled with VS 2013.

My call is:

test.exe -i points_relaxed.txt -w 1655 -h 1462

The TXT file contains 2640 point pairs, 60 KB.

How can I send you the TXT file with the input points?

[sanhoeeko]

I encountered the same issue (a rapid out of memory) in Windows 10. It rarely happens (about once in 5,000 diagrams) but is very hard to handle. "try ... catch" in c++ cannot handle this exception. And I'm not sure why it occurs for now. Maybe some of my data hits some marginal cases.
Could you please send me the data that reproduces this issue? I'm interested about the cause. My email is 806301104@qq.com.

[gorza47]

The TXT file is attached, call with: test.exe -i points_relaxed.txt -w 1655 -h 1462

points_relaxed.txt

I found some solutions to the endless loop problem in "jcv_boxshape_fillgaps".

1. Set a bigger number of sites than the real (counted) number (e.g. +256 or +1024) and allocate the points array with that number.

2. Better: in "jcv_boxshape_fillgaps" count the maximal number of loops/edges per polygon and exit the loop.
   (in "while( current && next )")
   In my tests, the maximal number of edges was 10 ... so, count the loops/edges and if > 10, break the loop.

[sanhoeeko]

voronoi-debug.zip

Perhaps I worked it out.

I don't remember well, but I think sweep line algorithms (like Fortune's algorithm) are vulnerable to exactly equal x (or y) coordinates. Therefore, adding a perturbation to the original data will help. Of course, we need some tricks to avoid the perturbation itself being equal again. For details, please see files attached.

[gorza47]

Hm, imho, the perturbation is not a safe or simple solution ... we need something than 100% works.