cilk_for segmentation fault

[Chris_Szalwinski]

Hi,

I'm having difficulty comparing cilk_for with cilk_spawn.  The following cilk_spawn code executes as I expect for command line arguments like 1000000 30

// Recursive Implementation of Map
// r_map.3.cpp

#include <iostream>
#include <iomanip>
#include <cstdlib>
#include <ctime>
#include <cmath>
#include <cilk/cilk.h>

const double pi = 3.14159265;

template<typename T>
class AddSin {
	T* a;
	T* b;
  public:
    AddSin(T* a_, T* b_) : a(a_), b(b_) {}
    void operator()(int i) { a = b + std::sin(pi * (double) i / 180.) + std::cos(pi * (double) i / 180.) + std::tan(pi * (double) i / 180.); }
};

template <typename Func>
void r_map(int low, int high, int grain, Func f) {
	if (high - low <= grain)
		for (int i = low; i < high; i++)
			f(i);
	else {
		int mid = low + (high - low) / 2;
		cilk_spawn r_map(low, mid, grain, f);
	}
}

int main(int argc, char** argv) {
	if (argc != 3) {
		std::cerr << "Incorrect number of arguments\n";
		return 1;
	}
	int n = std::atoi(argv[1]);
	int g = std::atoi(argv[2]);
	int* a = new int;
	int* b = new int;
	for (int i = 0; i < n; i++) {
		a = b = 1;
	}
	clock_t cs = clock();
	r_map(0, n, g, AddSin<int>(a, b));
	clock_t ce = clock();
	std::cout << ce - cs / (double)CLOCKS_PER_SEC << std::endl;
	delete [] a;
	delete [] b;
}

If I replace the body of r_map with a simple cilk_for loop and set the number of workers environment variable to more than 1, this code generates segmentation faults once my command line arguments exceed 36000 30

// Recursive Implementation of Map
// r_map.2.cpp

#include <iostream>
#include <iomanip>
#include <cstdlib>
#include <ctime>
#include <cmath>
#include <cilk/cilk.h>

const double pi = 3.14159265;

template<typename T>
class AddSin {
	T* a;
	T* b;
  public:
    AddSin(T* a_, T* b_) : a(a_), b(b_) {}
    void operator()(int i) { a = b + std::sin(pi * (double) i / 180.) + std::cos(pi * (double) i / 180.) + std::tan(pi * (double) i / 180.); }
};

template <typename Func>
void r_map(int low, int high, int grain, Func f) {
	cilk_for (int i = low; i < high; i++)
		f(i);
}

int main(int argc, char** argv) {
	if (argc != 3) {
		std::cerr << "Incorrect number of arguments\n";
		return 1;
	}
	int n = std::atoi(argv[1]);
	int g = std::atoi(argv[2]);
	int* a = new int;
	int* b = new int;
	for (int i = 0; i < n; i++) {
		a = b = 1;
	}
	clock_t cs = clock();
	r_map(0, n, g, AddSin<int>(a, b));
	clock_t ce = clock();
	std::cout << ce - cs / (double)CLOCKS_PER_SEC << std::endl;
	delete [] a;
	delete [] b;
}

I'm compiling using GCC 4.9.0 20130520.

Can you explain why cilk_spawn works while cilk_for does not?

[Barry_T_Intel]

I'm compiling using GCC 4.9.0 20130520.

We're still working with the GCC developers to get cilk_for into the 4.9 compiler. Are you sure you're using GCC 4.9?

    - Barry

[Chris_Szalwinski]

Am I using GCC 4.9?

From what I see, yes I am:

<pre>

chris.szalwinski@matrix:~> /usr/local/gcc/gcc-cilk/bin/g++ --version
g++ (GCC) 4.9.0 20130520 (experimental)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

</pre>

[Barry_T_Intel]

It's been pointed out to me that you must be using the cilkplus branch of 4.9. I've pulled it have it building now. I'll let you know what I find.

   - Barry

[Barry_T_Intel]

It's running fine for me. I'm running on Ubuntu 12.04.2 LTS on an Intel Core I7-2600 CPU w/4 cores, 2 threads/core.

This version of GCC shows the same version number as you.

Can you run the application under GDB and get a stacktrace?

   - Barry

[Chris_Szalwinski]

I've recompiled the original applications using the re-installed compiler (March 23 2014) and now they run as expected - no segmentation fault.  The cause of the original problem may have been the dated compiler (May 20 2013).  I got confused on version number temporarily - thinking that I had re-installed that old compiler, when in fact I had re-installed the latest revision (March 23 2014). 

Thanks Barry for your assistance and patience.

Chris