SpatioTemporal / STARE

SpatioTemporal Adaptive Resolution Encoding, a unifying index for geo-located data.
Other
10 stars 7 forks source link

Segmentation fault for very specific hull range lookup #39

Closed NiklasPhabian closed 4 years ago

NiklasPhabian commented 4 years ago

The error (segmentation fault) can be provoked e.g. from pystare as:

` import pystare

x = [0.0017, 0.0011, 0.0011, 0.0003, 0.0003, 0.0008, 0.0008, 0.0, 0.0, 0.0007] y = [4.0003, 4.0003, 4.0006, 4.0006, 4.0003, 4.0003, 4.0, 4.0, 4.0003, 4.003]

pystare.to_hull_range_from_latlon(y, x, 16) `

Or from CLI: lookupPolygon --resolution=16 --corners 0.0017 4.0003 0.0011 4.0003 0.0011 4.0006 0.0003 4.0006 0.0003 4.0003 0.0008 4.0003 0.0008 4.0 0.0 4.0 0.0 4.0003 0.0007 4.003`

Modifications to the arrays (shift left/right/up/down) or changing the order of points will result in the error not being provoked.

The error seems to appear during the doHull() routine of the SpatialInterface. More precisely during the domain() routine at domain.intersect(index_, &htmRange, hullinteriorp);

This is how the polygon looks like (with overlaying trixels) Polygon

NiklasPhabian commented 4 years ago

The error can also be produced with a smaller subset. But this is just a line rather than a polygon. 0 ( 4.0003 0.0017) 1 ( 4.0003 0.0011) 2 ( 4.0003 0.0003) 3 ( 4.0003 0.0008)

michaelleerilee commented 4 years ago

Is the segmentation fault being driven by a set of co-linear points? Michael Lee Rilee, Ph.D.Rilee Systems Technologies LLCContact: mike@rilee.net; Phone: 703-348-8127; Cell: 240-481-3254; Fax: 703-880-7202

On Wednesday, February 12, 2020, 03:51:28 PM EST, Niklas Griessbaum <notifications@github.com> wrote:  

The error can also be produced with a smaller subset. But this is just a line rather than a polygon. 0 ( 4.0003 0.0017) 1 ( 4.0003 0.0011) 2 ( 4.0003 0.0003)

3 ( 4.0003 0.0008)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

NiklasPhabian commented 4 years ago

Maybe. But lookupPolygon --resolution=16 --corners 0.0011 4.0003 0.0003 4.0003 0.0008 4.0003 0.0017 4.0003 Yields expected result. While lookupPolygon --resolution=16 --corners 0.0017 4.0003 0.0011 4.0003 0.0003 4.0003 0.0008 4.0003

Causes segmentation fault. They are the same points, but in reverse order.

michaelleerilee commented 4 years ago

It looks like the  equivalent and antipodal constraints calculated by cross-multiplying vertices are not correctly detected during the simplification step. Please try the following. Look for simplify0 in src/RangeConvex.cpp and make the following change.

// float64 tol = 1.0e-12; // 1.0e-12 * RE ~ 6e-6 m

// float64 tol2 = tol*tol;

float64 tol  = 1.0e-10; // 1.0e-10 * RE ~6e-4 m

float64 tol2 = tol; Note to self: All hardcoded parameters should be "dependency injected" to environment variables (with defaults). Also: We should come up with some stress tests that deliberately abuse the system. Michael Lee Rilee, Ph.D.Rilee Systems Technologies LLCContact: mike@rilee.net; Phone: 703-348-8127; Cell: 240-481-3254; Fax: 703-880-7202

On Wednesday, February 12, 2020, 06:47:02 PM EST, Niklas Griessbaum <notifications@github.com> wrote:  

Maybe. But lookupPolygon --resolution=16 --corners 0.0011 4.0003 0.0003 4.0003 0.0008 4.0003 0.0017 4.0003 Yields expected result. While lookupPolygon --resolution=16 --corners 0.0017 4.0003 0.0011 4.0003 0.0003 4.0003 0.0008 4.0003

Causes segmentation fault. They are the same points, but in reverse order.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub, or unsubscribe.

michaelleerilee commented 4 years ago

How is this looking now?

NiklasPhabian commented 4 years ago

It seems like this fixes the issue for small/incomplex regions.

However, I cannot seem to get the convexHull for any more complex region of 100+ constraints though.

Sometimes I get segmentation faults, sometimes the system seems to hang/spin forever, occasionally, I get the string "corrupted size vs. prev_size" thrown at the console. It does not look like this is not STARE throwing this string.

Example polygon below. Interestingly enough, I can translate this polygon around. Even round the numbers to some degree. The error persists. But if I change the order of the nodes (e.g. inverse), STARE can create the Hull.

lookupPolygon --resolution=16 --corners 0.01389 0.01056 0.00278 0.00278 0.01333 0.01111 0.00333 0.0025 0.01222 0.00083 0.00472 0.01084 0.00417 0.01167 0.00972 0.00028 0.00166 0.00389 0.00333 0.00278 0.00361 0.00222 0.00055 0.00806 0.01056 0.00028 0.01528 0.00778 0.01416 0.00333 0.00222 0.00306 0.00472 0.00167 0.00472 0.00195 0.00444 0.01 0.01555 0.00556 0.01416 0.01028 0.01389 0.0025 0.015 0.00445 0.00278 0.00306 0.01444 0.00333 0.01528 0.005 0.00194 0.00889 0.01361 0.0025 0.01472 0.00361 0.00139 0.00389 0.00055 0.00556 0.0025 0.00917 0.00528 0.00139 0.01583 0.00583 0.00917 0.00056 0.00833 0.00056 0.0025 0.00945 0.01056 0.0 0.01305 0.01111 0.01278 0.00139 0.01111 0.00056 0.01528 0.00861 0.01528 0.00445 0.01583 0.00667 0.01139 0.00056 0.00417 0.01195 0.00917 0.00028 0.00111 0.00861 0.01361 0.01084 0.00389 0.01111 0.01472 0.00417 0.01333 0.00167 0.00333 0.00972 0.00528 0.00167 0.01611 0.00667 0.00083 0.00806 0.00194 0.00917 0.00444 0.00972 0.01444 0.00945 0.00027 0.00778 0.01389 0.01028 0.015 0.00917 0.01416 0.00306 0.00333 0.00945 0.01278 0.01167 0.01361 0.01056 0.01472 0.00945 0.00833 0.00084 0.01278 0.01222 0.00055 0.005 0.00566 0.00139 0.01444 0.00972 0.00694 0.00083 0.01278 0.00111 0.00444 0.01084 0.00083 0.00472 0.01583 0.00556 0.01305 0.01167 0.01555 0.00778 0.00389 0.01167 0.00111 0.00833 0.015 0.00861 0.015 0.00417 0.00583 0.00111 0.00083 0.005 0.00583 0.00139 0.00472 0.01 0.01611 0.00583 0.01333 0.00139 0.00166 0.00889 0.00166 0.00861 0.01416 0.00972 0.00055 0.00778 0.00166 0.00333 0.01444 0.00361 0.01555 0.0075 0.00361 0.0025 0.00972 0.0 0.0 0.0075 0.00083 0.00833 0.00444 0.01111 0.00027 0.0075 0.01583 0.0075 0.00222 0.00333 0.01139 0.00084 0.0 0.00583 0.00027 0.00583 0.01222 0.00111 0.01361 0.00167 0.00139 0.00472 0.00417 0.00222 0.00694 0.00111 0.01333 0.01084 0.01555 0.005 0.01389 0.00306 0.0125 0.01222 0.00027 0.00556 0.01111 0.00028 0.00417 0.00195 0.01472 0.00917

michaelleerilee commented 4 years ago

I'm getting a free() error on the final return from const HTMRangeValueVector & 

htmInterface::domain( SpatialDomain & domain ) back up to STARE::ConvexHull. So it looks like something is being improperly deleted.

Michael Lee Rilee, Ph.D.Rilee Systems Technologies LLCContact: mike@rilee.net; Phone: 703-348-8127; Cell: 240-481-3254; Fax: 703-880-7202

On Thursday, February 20, 2020, 07:07:22 PM EST, Niklas Griessbaum <notifications@github.com> wrote:  

It seems like this fixes the issue for small/incomplex regions.

However, I cannot seem to get the convexHull for any more complex region of 100+ constraints though.

Sometimes I get segmentation faults, sometimes the system seems to hang/spin forever, occasionally, I get the string "corrupted size vs. prev_size" thrown at the console. It does not look like this is not STARE throwing this string.

Example: lookupPolygon --resolution=16 --corners 0.01389 0.01056 0.00278 0.00278 0.01333 0.01111 0.00333 0.0025 0.01222 0.00083 0.00472 0.01084 0.00417 0.01167 0.00972 0.00028 0.00166 0.00389 0.00333 0.00278 0.00361 0.00222 0.00055 0.00806 0.01056 0.00028 0.01528 0.00778 0.01416 0.00333 0.00222 0.00306 0.00472 0.00167 0.00472 0.00195 0.00444 0.01 0.01555 0.00556 0.01416 0.01028 0.01389 0.0025 0.015 0.00445 0.00278 0.00306 0.01444 0.00333 0.01528 0.005 0.00194 0.00889 0.01361 0.0025 0.01472 0.00361 0.00139 0.00389 0.00055 0.00556 0.0025 0.00917 0.00528 0.00139 0.01583 0.00583 0.00917 0.00056 0.00833 0.00056 0.0025 0.00945 0.01056 0.0 0.01305 0.01111 0.01278 0.00139 0.01111 0.00056 0.01528 0.00861 0.01528 0.00445 0.01583 0.00667 0.01139 0.00056 0.00417 0.01195 0.00917 0.00028 0.00111 0.00861 0.01361 0.01084 0.00389 0.01111 0.01472 0.00417 0.01333 0.00167 0.00333 0.00972 0.00528 0.00167 0.01611 0.00667 0.00083 0.00806 0.00194 0.00917 0.00444 0.00972 0.01444 0.00945 0.00027 0.00778 0.01389 0.01028 0.015 0.00917 0.01416 0.00306 0.00333 0.00945 0.01278 0.01167 0.01361 0.01056 0.01472 0.00945 0.00833 0.00084 0.01278 0.01222 0.00055 0.005 0.00566 0.00139 0.01444 0.00972 0.00694 0.00083 0.01278 0.00111 0.00444 0.01084 0.00083 0.00472 0.01583 0.00556 0.01305 0.01167 0.01555 0.00778 0.00389 0.01167 0.00111 0.00833 0.015 0.00861 0.015 0.00417 0.00583 0.00111 0.00083 0.005 0.00583 0.00139 0.00472 0.01 0.01611 0.00583 0.01333 0.00139 0.00166 0.00889 0.00166 0.00861 0.01416 0.00972 0.00055 0.00778 0.00166 0.00333 0.01444 0.00361 0.01555 0.0075 0.00361 0.0025 0.00972 0.0 0.0 0.0075 0.00083 0.00833 0.00444 0.01111 0.00027 0.0075 0.01583 0.0075 0.00222 0.00333 0.01139 0.00084 0.0 0.00583 0.00027 0.00583 0.01222 0.00111 0.01361 0.00167 0.00139 0.00472 0.00417 0.00222 0.00694 0.00111 0.01333 0.01084 0.01555 0.005 0.01389 0.00306 0.0125 0.01222 0.00027 0.00556 0.01111 0.00028 0.00417 0.00195 0.01472 0.00917

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub, or unsubscribe.

michaelleerilee commented 4 years ago

Just found the test is segfaulting on CentOS 7 but not Fedora 31. Will have to look into this more closely.

michaelleerilee commented 4 years ago

An array size declaration was wrong leading to the segfault.