Can someone help me identify possible race conditions in this code I have?

[MutantJohn]

So, I keep getting that I'm constructing a negatively oriented tetrahedron but I get it sporadically so I'm not sure. Here's the github link : https://github.com/LeonineKing1199/HardWayHome

And unfortunately my code does use the library Eigen so if you wanna run it, it needs it.

But the thing about the error is, my walk function only collects tetrahedra in which the point I'm trying to insert is above all 4 faces so it's perfectly contained.

I don't know if that was enough explanation but valgrind seems to fix my error and I only get random crashes. It's not like I'm reading/writing wrong but rather, I'm getting odd negative fractures.

[Codeplug]

Quick review w/o understanding the code:

Makefile - You should compile with "-pthread" instead of "-lpthread". The former will apply everything needed for threading (defines, additional libs, etc...) where the later just links with libpthread. This is a GNU convention but I believe other compilers support it as well.

structures.hpp
- "static int quadrants" - by putting this in a header, every translation unit (TU) that includes it will contain is own copy. Since it's read-only data, it's not causing any problems. Typically, headers will "extern" global data with the definition in a single TU.

- lines 187,190 - Calling vector::reserve() and then caching the data() pointer seems dangerous at best. reserve() only affects the capacity and not the size, so there officially isn't anything stored in the vectors yet. Also, if you happen to exceed the capacity (or reallocation occurs for some other reason - if that exists) then your cached pointers will be invalid.

gg

[Salem]

Perhaps you could run it through helgrind instead.
Valgrind

[MutantJohn]

I fixed my code by literally copying and pasting one line to a different location. I took the curr pointer definition from outside the lambda in the main.cpp and put inside it and voila, it all seems to work. I mean, wow. Just. Wow.

[Codeplug]

I wouldn't be wow'd unless you identified a specific bug and fixed it . In this case you seem to have done that:

	for (unsigned int i = 0; i < num_threads; ++i) {
	
		auto curr = buff[i].tetra_buffer.data();
		auto p = buff[i].point_position;

		threads.emplace_back([&buff, i, &curr, p]() {
...

Both "curr" and "p" are scoped to the for loop. So when the loop continues, curr and p go out of scope and are recreated/reset. The threads are running asynchronously to the for loop and curr is passed by reference. Assuming the same stack location is used for curr on each iteration, the threads are having their curr values changed out from underneath them. That's bad

Making curr and p local thread variables makes sense to me since they can be created through buff and i which are already being passed.

gg

[MutantJohn]

Wow, helgrind is godlike. Thank you so much for showing me this, omg.

[Elysia]

There is always Intel's developer tools... I believe they're free for Linux. Inspector can help you find races.