search

tudelft3d / prepair

Automatic repair of single polygons (according to the OGC Simple Features / ISO19107 rules) using a constrained triangulation.
GNU General Public License v3.0
115 stars 24 forks source link

Segmentation Fault (core dumped) when running on large polygons #18

Open tronxd opened 9 years ago

tronxd commented 9 years ago

when running at your dataset (Data/CLC2006_180927.geojson) prepair --ogr CLC2006_180927.geojson I get a segmentation fault (core dumped) (small polygons are ok) DETAILS: branch: master: OS: RHEL 6.2 (Santiago) compiled by gcc 4.4.7 Boost 1.41.0 CGAL 4.6

kenohori commented 9 years ago

Thanks for the report! I'm quite busy at the moment, but I'll install Red Hat in a VM to debug it when I can.

However, my best guess would be that there is a problem with the GMP or MPFR libraries, which are needed for exact arithmetic. Did you compile them yourself or got them from a repository? In RPM perhaps?

tronxd commented 9 years ago

Hello Ken, These libraries were installed from a Yum repository.

aj7 commented 7 years ago

any ideas on this? i am also getting the same

entranOA commented 6 years ago

Any updates on this issue? I'm having the same issue while trying to prepair polygons that span the entirety of the USA land boundary.

kenohori commented 6 years ago

Sorry, but it wasn't a trivial thing to debug and I've been busy with other projects. I'll have another look at it.

entranOA commented 6 years ago

Thank you! I was using the improvements-with-ogr branch.

1riggs commented 6 years ago

I ran into the same issue with the improvements-with-ogr branch, that it was producing a segmentation fault when processing large/complex polygons. After some investigation, it appeared the cause was a certain malloc call, which results in a stack overflow. I circumvented the issue by setting the core file size (I don't think core file size change is necessary, but haven't tried it without it) and the stack size to unlimited. I was able to process the polygons which were previously resulting in the aforementioned error.

albanm commented 6 years ago

@AlexRiggs how did you increase the stack size to unlimited ? On ubuntu I tried using "ulimit -s", it didn't fix the problem, I don't know if it is the right command.

1riggs commented 6 years ago

@albanm the commands I used are as follows:

ulimit -c unlimited
ulimit -s unlimited
ulimit -a

the -a flag just displays the ulimit settings, use it to verify the changes. Hope this helps!

albanm commented 6 years ago

Thanks! Unfortunately it seems that my problem is not related to the polygon size.

After closer inspection it happens on a small broken polygon (4 points including 2 duplicates).

1riggs commented 6 years ago

Ah that's a shame. You may have already thought of this but it may be easiest to load the polygon into QGIS or ArcGIS, select that specific polygon and repair it by hand or with one of the built-in repair tools. It sounds like it may just be a weird unhandled edge case for prepair.

If that doesn't work, the other thing you could try is running prepair with the bash C-debugger (gdb) and check the log files, might give you a more informative error than just Segmentation Fault.

Best of luck!

On Tue, Sep 11, 2018 at 11:04 AM, Alban Mouton notifications@github.com wrote:

Thanks! Unfortunately it seems that my problem is not related to the polygon size.

After closer inspection it happens on a small broken polygon (4 points including 2 duplicates).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tudelft3d/prepair/issues/18#issuecomment-420346958, or mute the thread https://github.com/notifications/unsubscribe-auth/Ad6A0XkwJMzHiCM8sUcbPrgZgjQ2lhC-ks5uZ-0qgaJpZM4EI_ho .

albanm commented 6 years ago

It is alright in the end, this polygon is actually impossible to repair in my opinion and it is just one in many in a large dataset. So I just catch the error, log it, consider that I did the best I could and go on to the next feature. I use prepair as well as turfjs' cleanCoords and rewind, and it seems that almost all features are clean afterwards.