crash when used as face-view labeling

[cdcseacave]

I tried to use it as demonstrated in mvs_texturing, but for some meshes it crashes:

I can send the mesh, but I do not see an easy way to dump the mapmap problem to a file to send you the problem.

[xubury]

Hey, I ran into the exact same problem as yours. Did you work it out eventually?

[xubury]

but for some meshes it crashes:

For me, I didn't find out a single working mesh...

[dthuerck]

Hi there,

I'd be happy tro investigate that. If you send me the mesh and instructions to replicate, I'll take a shot at it (at least under Linux).

[xubury]

Hi there,

I'd be happy tro investigate that. If you send me the mesh and instructions to replicate, I'll take a shot at it (at least under Linux).

Hi, this is one of my meshes that is keep getting the segmentation fault. I have tried it on Linux(Ubuntu) and it works fine on it.
https://drive.google.com/file/d/1nJ9ZDvfvBihSqb-oXHONyZC1fqiuvODk/view?usp=sharing
I tried to debug it for serveral days now. I suspect it's related to some array alignment problems like the link below.
https://stackoverflow.com/questions/62324009/mm256-load-ps-cause-segmentation-fault-with-google-benchmark-in-debug-mode
BTW, I am using MinGW-w64 GCC (10.2.0) as compiler on windows10.

[xubury]

actually, you may not need the mesh. I ran into the same issue in mapmap_demo or mapmap_test.
It always crashed here.

I can't figure out why this can trigger a segmentation fault. After some tries, I changed the line a little bit.

diff --git a/mapmap/source/optimizer_instances/dp_node_solver.impl.h b/mapmap/source/optimizer_instances/dp_node_solver.impl.h
index 63498f8..5f82c87 100644
--- a/mapmap/source/optimizer_instances/dp_node_solver.impl.h
+++ b/mapmap/source/optimizer_instances/dp_node_solver.impl.h
@@ -246,7 +246,8 @@ get_independent_of_parent_costs(
         label_from_offset(node_id, 0);

     /* vector holding costs */
-    _v_t<COSTTYPE, SIMDWIDTH> cost = v_init<COSTTYPE, SIMDWIDTH>();
+    _s_t<COSTTYPE, SIMDWIDTH> test = 0;
+    _v_t<COSTTYPE, SIMDWIDTH> cost = v_init<COSTTYPE, SIMDWIDTH>(test);

     /* retrieve label vector for this offset */
     _iv_t<COSTTYPE, SIMDWIDTH> l = m_node->c_labels->

Then I not longer received the segmentation fault in that line. Instead, I crashed in the few lines below.

    cost = c_unary->supports_enumerable_costs() ?
        v_add<COSTTYPE, SIMDWIDTH>(cost,
        c_unary->get_unary_costs_enum_offset(l_i)) :
        v_add<COSTTYPE, SIMDWIDTH>(cost, c_unary->get_unary_costs(l));

[dthuerck]

Interesting - so far, I seem to be unable to reproduce it. Can you name me the CPU you're using so I can narrow this down to the right instruction set (AVX/2, SSE, ...)?

[dthuerck]

One further thing to try would be edit all v_load variants in source/vector_math.impl.h so they always use the unaligned intrinsics (loadu). I'll see if I can get my hands on a windows machine to test that.

[xubury]

Interesting - so far, I seem to be unable to reproduce it. Can you name me the CPU you're using so I can narrow this down to the right instruction set (AVX/2, SSE, ...)?

My CPU is Intel(R) Core(TM) i3-8100 CPU @ 3.60GHz (4 CPUs), ~3.6GHz

[xubury]

One further thing to try would be edit all v_load variants in source/vector_math.impl.h so they always use the unaligned intrinsics (loadu). I'll see if I can get my hands on a windows machine to test that.

Just tested it, no luck though.

[xubury]

Surprisingly, I tested mapmap_demo compiled by MVSC and NO SegFault! Though as #21 mention, I have to change the line in prev_level().
I was using MinGW-GCC 10.2.0 as compiler, maybe the tbb provieded by msys2's package manager has some issues. I will try to rebuild it to see if the problem still exsits.

Update: I just rebuild tbb with MinGW-GCC and still get the segmentation fault...

[xubury]

I can confirm that my bug is related to the compiler, there've been serval discussion about this bug.
https://stackoverflow.com/questions/30928265/mingw64-is-incapable-of-32-byte-stack-alignment-required-for-avx-on-windows-x64
https://sourceforge.net/p/mingw-w64/mailman/message/34485783/

[dthuerck]

Ah, too bad, it's a compiler bug. Are you able to switch to VS? I'll push the change in #21 upstream.

Regarding this problem, I only see two possibilities going forward:

1. Avoid MinGW ;)
2. Move variables from stack to heap.

[xubury]

Ah, too bad, it's a compiler bug. Are you able to switch to VS? I'll push the change in #21 upstream.

Regarding this problem, I only see two possibilities going forward:

1. Avoid MinGW ;)

2. Move variables from stack to heap.

Yeah, but I was able to avoid the problem by setting simd width to 4 using mingw. I don't know what it will do to the final outcome though.

[melhashash]

@xubury @dthuerck
I am facing the same issue reported here by @cdcseacave. I packed the problem to a bin file in this issue #37 (comment)