Crashes when changing view properties with certain data

[omgitsraven]

I'm not sure if I should list these two crashes as two separate issues, but they have similar triggers and use the same data, so I'll just list them together here for now.

I'm working on a model, and I've wound up in a position where if I make certain changes to the bounding box, or if I turn the resolution up past a certain amount, Ao crashes (either instantly, or after several seconds).

I'm on macOS 10.12.6, and I'm using the latest files on github as of this posting (the Oct 16 commits).

I've stripped down my file to as small as it can get while still triggering the bug. I've attached it here (zipped so github will accept it): idol_CRASHDEMO.zip

CRASH 1: Open the view options menu, and change the bounds for the X dimension to -1.5 and 1.5
In a previous build, it would crash as soon as the first number was changed; after updating to the latest build it seems like it only crashes as soon as you try to change the second number.

CRASH 2: Open the view options menu, and change the resolution to anything above 64, then wait a few seconds.

I'm pretty sure some of my operations aren't exactly distance-preserving, but it's always seemed to work out fine until now; could the crash be caused by the 'impossible' distance fields becoming a problem when the resolution gets precise enough?

[omgitsraven]

fwiw, turning down the resolution then scaling up the model in code (after increasing the bounds to make room) also causes Crash 2, so it does seem like it has to do with trying to render that function at a certain amount of detail, rather than just something about the literal resolution value itself.

[omgitsraven]

OK, I've found a couple of new situations that will crash Ao, one of which might not be related to this thread but I'll include it anyway since I have a feeling it'll still be useful -- and the other of which is DEFINITELY related, and is the simplest test case yet, and doesn't do anything to "cheat" the distance function, which should rule that out as a possible cause...

CRASH 3:

idol_CRASH3.zip

In the line:
(scale x y z 1 0.5 1 (lambda (x y z)
change the second 1 to a 2, to make it
(scale x y z 1 0.5 2 (lambda (x y z)
and Ao will instantly crash.

CRASH 4:

idol_CRASH4.zip

Change the negative end of the Z axis of the bounding box from -6 to -8, and Ao will instantly crash.

[mkeeter]

I added CRASH4 as a unit tests, where it reproduces the problem.

The issue here is that during meshing, two evaluations of the same point give slightly different values (?!). The first evaluation gives 0, which is inside the shape; the second gives a tiny positive value (1e-9 or so), which is outside.

There's something strange going on with Eigen: if I disable vectorization with -D EIGEN_DONT_VECTORIZE -D EIGEN_DISABLE_UNALIGNED_ARRAY_ASSERT), the test passes, but other unrelated tests start failing (?!).

Anyways, 5f89d8a should work around the issue by not doing the second evaluation (so there's no room to disagree). This fixes all the tests cases above on my machine; can you pull and test it out?

[omgitsraven]

That fixes all four for me :) Thanks so much!