Comments (17)
Hey, I ran into the exact same problem as yours. Did you work it out eventually?
from mapmap_cpu.
but for some meshes it crashes:
For me, I didn't find out a single working mesh...
from mapmap_cpu.
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).
from mapmap_cpu.
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.
from mapmap_cpu.
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));
from mapmap_cpu.
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, ...)?
from mapmap_cpu.
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.
from mapmap_cpu.
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
from mapmap_cpu.
One further thing to try would be edit all
v_load
variants insource/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.
from mapmap_cpu.
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...
from mapmap_cpu.
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/
from mapmap_cpu.
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:
- Avoid MinGW ;)
- Move variables from stack to heap.
from mapmap_cpu.
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.
from mapmap_cpu.
@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)
from mapmap_cpu.
I think I might have found the reason, looks like the "labels" within the "label_set" are assumed to be sorted. If not, bad things happen. Correct?
from mapmap_cpu.
Solved by making sure labels are sorted.
cc: @cdcseacave in case you are still interested in trying it again.
from mapmap_cpu.
Thanks for investigating!
from mapmap_cpu.
Related Issues (20)
- Possible memory leak in TreeSampler
- how to use it with tbb? HOT 1
- How can I change the weight of unary costs and pairwise costs? HOT 2
- crashed at runtime when linked to tbb 2018_U5 HOT 3
- Variable length array causes issues when compiling with MSVC HOT 4
- <opencv2/opencv.hpp> can influence the optimize( std::vector<_iv_st<COSTTYPE, SIMDWIDTH>>& solution,const mapMAP_control& control_flow) in mapmap/source/mapmap.impl.h. HOT 5
- MSVC debug mode assertion in void PairwiseTable<COSTTYPE, SIMDWIDTH>:: set_costs HOT 4
- Illegal instruction crashes on mac HOT 1
- SSE2 HOT 4
- bug in prev_level() HOT 3
- Customizing pairwise costs HOT 1
- why only set pairwise once? HOT 1
- Compilation error since commit 986e1ab3 HOT 4
- oneTBB removes tbb::task HOT 2
- Is arm linux supported? HOT 1
- Compile error: internal compiler error: Segmentation fault HOT 1
- Crash in dp_node_solver.impl.h HOT 2
- Setting Pairwise costs table from a std::vector fails HOT 1
- Possible memory leak in pairwise_table.impl.h HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mapmap_cpu.