union of shapes sometimes results in error

[Loosetooth]

I have this example code doing a basic path sweep. It generates lots of small linear extrusions and partial revolves, which when unioned together form a shape:

You can find the example code here. Just copy and paste in manifoldcad.org

I noticed that when scaling the path up and down, for some scale factors, seemingly randomly, the manifold generation results in an error. On line 8 of the example code above you can change the scale factor. When changing it to 1 or 0.2, an error is thrown:

RuntimeError: Aborted(). Build with -sASSERTIONS for more info.

Any idea on how to proceed to debug this error?
Should I rebuild the .wasm file with the -sASSERTIONS flag as shown by the error, to get more info?
If I rebuild the .wasm file, is there an easy way for me to test it out in the browser with my local newly created .wasm file?

It's not immediately obvious to me how to debug this. Having an easy way to test a local .wasm build in the browser might also make the development of new bindings (at least for wasm) easier!

EDIT:
some extra information: using compose to combine all the tiny primitives together works just fine. So it seems to be specific to the union call.

[elalish]

I haven't had much luck debugging our C++ code through WASM, though I also haven't tried building with -sASSERTIONS. Still, generally I would start by making a minimal repro with a C++ TEST. Then you can build in MANIFOLD_DEBUG mode and generally get a lot more information. I haven't found any bugs in the WASM that didn't also repro in the C++ (unless it's something like out of memory).

Not surprising it doesn't repro with compose - that function has trivial complexity compared to the Booleans.

[elalish]

Okay, I merged in my changes, so here are the new directions for testing WASM. Still likely to be much easier to debug the C++ directly though.

[Loosetooth]

Thanks for the heads up regarding the local WASM build. I just tried out modifying the /bindings/wasm/CMakeLists.txt by adding the -sASSERTIONS=2 flag to the build. This results in the following error in the browser: RuntimeError: memory access out of bounds. This is already a bit more descriptive, but does not help us much I'm afraid.

I'm going to learn some more about debugging WASM using emscripten first, before trying to rewrite the js to c++.

I'll keep you up to date with anything new I find out.

[Loosetooth]

EDIT: Scratch this for now. It was a simple indexing problem. Re-running with correct indexing fixed the test for now.

Old comment for reference:
OK, I couldn't for the life of me figure out how to debug through WASM. So I went ahead and translated the code over to C++.

I wrote a test that you can find in the gist here.
If you copy the test in src/test/manifold_test.cpp and run the tests, it should pass fine.

Please note that the last path point on line 447 is commented. If you uncomment that point (this creates the original failing path), the test fails.

I tested a bit with commenting and uncommenting different points from the list. It seems to be really random to me if the test fails or passes. (This is also the case in WASM.)

The C++ test seems to reproduce the errors I'm getting in WASM almost exactly. (I.e. removing the last primitive in WASM also generates the shape just fine there.)

I also did a quick check if all the primitives have a positive volume:

// all primitives should be valid
for (Manifold primitive : result) {
  manifold::Properties properties = primitive.GetProperties();
  if (properties.volume < 0) {
    std::cerr << "INVALID PRIMITIVE" << std::endl;
  }
}

And this seemed to be the case. If there is a better way for me to check all the individual (tiny) primitives for validity, let me know.

[elalish]

Oh, interesting! Can you describe the indexing problem you found? It seems like if nothing else we should at least have a clearer error message somewhere.

[Loosetooth]

An array/vector index was out of bounds (due to my own coding error). So I didn't actually reproduce the bug yet. However, I managed to get the shape generated in the C++ test exported to GLB, and it looks almost like the shape from WASM, so I think I'm almost there:

Hopefully I can reproduce it soon.

[Loosetooth]

Alright, I wrote a C++ test case that generates exactly the same shape as in WASM. You can find it in this gist.

Copy and paste the code as a test in src/test/manifold_test.cpp. First build, and then run the test with:
test/manifold_test --gtest_filter=Manifold.UnionError

The test should run fine and print out the volume of the resulting shape.

On line 457 of the gist it's possible to change the scaling factor of the path. For now I found two scale factors that break the shape generation: 0.1 and 0.8.
To test, just change the scale factor in the test, rebuild and re-run the test.

It's also possible to export the resulting GLB file by running:
test/manifold_test --gtest_filter=Manifold.UnionError -e
This should generate a unionError.glb file, which can then be inspected. I had a look at a few results, and it looks exactly like the shape generated by my WASM example. It also has exactly the same volume as in WASM for the same scale factors. (So it seems like my test accurately generates the same shapes as in my WASM example.)

As for the errors it throws with scale factors 0.1 and 0.8:

• 0.1: it runs for quite a while longer than normal on my pc, then fails with Segmentation fault
• 0.8: runs a bit long, then:

unknown file: Failure
C++ exception with description "std::bad_alloc" thrown in the test body.

I'm not very experienced with C++, so I'm unsure how to debug this further at the moment.
Any extra guidance or help is very much appreciated!

[Loosetooth]

FWIW: Something interesting I noticed with the scale factors:
changing them by a tiny amount makes the error disappear. Trying with 0.8 for example:

0.8: FAIL
0.81: PASS
0.801: PASS
0.8001: PASS
...
0.8000001: PASS
0.80000001: FAIL

[elalish]

Excellent, thank you! Would you mind cutting down the test case to as minimal a repro as you can manage and submitting it as a PR? If you prepend the test name with DISABLED_ it'll allow the CI to pass for now. That'll make it easy for me to come back with a PR to fix it.

[Loosetooth]

Would you mind cutting down the test case to as minimal a repro as you can manage

It's a bit hard as the error is a little finicky to replicate, and I haven't managed to generate the error in any other way than the complex case.

I also tried to find a simpler shape that errors, to simplify the amount of code to translate into C++, but couldn't.
I'll open the pull request and we can look at simplification from there.

[Loosetooth]

Do you think it might be possible that the error occurs because of lots of coplanar faces having to be unioned together? The test I wrote generates a ton of primitives, which all have coplanar faces. Inspecting the final mesh that comes out, they don't always get unioned together. (Which is normal I guess.)

Perhaps this might be linked to the crash?

[elalish]

Yeah, probably so. Of course I have lots of tests of that kind of thing, so I'll just have to simplify this down to some new ones and go fix them. Sorry, I haven't had a chance to look at this yet as I've been in the midst of a big feature. I promise I'll get to it soon!

[Loosetooth]

No worries, you do it when you want, and have time. The bug is not a deal breaker for me.

[elalish]

Fixed in #447 - it was a problem with the decimator.