Creating a `grb::Vector< T, grb::reference >` when running with `bsp1d` backend gives runtime error

[GiovaGa]

Consider the following:

#include <graphblas.hpp>

void grb_program( const int &in, int &out ) {
	const size_t s = grb::spmd<>::pid();
	const size_t n = 10;

	std::cerr << "Hello0 from process " << s << std::endl;

	grb::Vector< int > x( n );
	grb::RC rc = grb::SUCCESS;

	grb::Vector< int, grb::reference > mask ( n );
	std::cerr << "Hello1 from process " << s << std::endl;
	assert( rc == grb::SUCCESS );
}

int main( int argc, char ** argv ) {
	int n = 42;
	int error_code = 100;

	grb::Launcher< grb::AUTOMATIC > launcher;
	assert( launcher.exec( &grb_program, n, error_code, true )
		== grb::SUCCESS );
	return error_code;
}

The code compiles without warnings or errors. When running this program terminates with signal 11 (segfault). The output is something like the following:

Info: grb::init (BSP1D) called using 2 user processes.
Info: grb::init (reference) called.
Info: grb::init (reference) called.
Hello0 from process 0
Hello0 from process 1
Info: process mask is all-one, we therefore assume a single user process is present on this node and thus shall use aligned mode for memory allocations that are potentially touched by multiple threads.
Info: process mask is all-one, we therefore assume a single user process is present on this node and thus shall use aligned mode for memory allocations that are potentially touched by multiple threads.
Hello1 from process 0
Info: grb::finalize (bsp1d) called.
	 process 0 is finalising

a.out:25405 terminated with signal 11 at PC=706556ac658e SP=7ffc2f206538.  Backtrace:
[...]

It is notable that if the template argument of launcher instead of grb::AUTOMATIC is grb::FROM_MPI (with the suitable mpi initializations), the same program runs fine.

[GiovaGa]

Some observations:

• The program runs fine if the size of grb::Vector< int, grb::reference > mask ( n ); is zero.
• The Segmentation Fault is thrown when the reference map is updated, that is in file include/graphblas/utils/DMapper.hpp:112. The interesting thing is that this line is an insertion in an empty std::map. So this suggests that there is some other undesired memory problem before this point

My hypothesis is that the problem is that the reference_mapper automatically instantiated, is not correctly constructed for some reason. But I will explore better this possibility.

[GiovaGa]

Note that the issue has been replicated with gcc 11.4.0 and gcc 9.5.0