# bugs in cilkprof

## bugs in cilkprof

Hi,

I found a possible bug in cilkprof. I installed the cilkprof following instructions in libzca, cilkprof, and pintool (2.10).

When I ran my code with cilkprof as:

\$ LD_LIBRAY_PATH=./3rdparty/pintool/intel64/lib-ext/:\$LD_LIBRARY_PATH CILKPROF_CC_OUT=heat_2D_P.cc CILKPROF_BB_OUT=heat_2D_P.bb 3rdparty/pintool/pin -t cilkutil/cilkprof/linux64/cilkprof.so -- ./heat_2D_P 200 200
N_SIZE = 200, T_SIZE = 200
a(T+1, J, I) = 0.125 * (a(T, J+1, I) - 2.0 * a(T, J, I) + a(T, J-1, I)) + 0.125 * (a(T, J, I+1) - 2.0 * a(T, J, I) + a(T, J, I-1)) + a(T, J, I)
shorter_duo_sim_obase_bicut_p!
Pochoir ET: consumed time :1127.56ms
pinbin: sprof.h:155: unsigned int sprof_t::get(unsigned int) [with T = sprof_single_t]: Assertion `this->m_table->size() >= i' failed.
Aborted

Best!

-Yuan

3 posts / 0 new
For more complete information about compiler optimizations, see our Optimization Notice.

I can elicit the same bug from the following variant of fib. (Thanks to Eka Palamadi for the original fib source that demonstrates this bug.)
#include #include #include #include int fib(int n) { if (n < 2) { return n; } int x, y; x = cilk_spawn fib(n-1); y = fib(n-2); cilk_sync ; return x+y;}int main(int argc, char* argv[]) { int n = 10; if (argc > 1) { n = atoi(argv[1]); } int result = fib(n); //std::cout << "fib(" << n << ") = " << result << "\n"; printf("fib(%d) = %d\n", n, result); return 0;}If I compile this program (with icc 12.1.4) and run it with cilkprof, I see:\$LD_LIBRARY_PATH=./3rdparty/pintool/intel64/lib-ext:\$LD_LIBRARY_PATH CILKPROF_CC_OUT=fib.cc CILKPROF_BB_OUT=fib.bb 3rdparty/pintool/pin -t cilkutil/cilkprof/linux64/cilkprof.so -- ./fib 10fib(10) = 55pinbin: sprof.h:155: unsigned int sprof_t::get(unsigned int) [with T = sprof_single_t]: Assertion `this->m_table->size() >= i' failed.AbortedInterestingly, if I comment out the line "#include ", recompile, and rerun with cilkprof, I do not see the error.Hope this helps,TB

I just posted a new copy of cilkprof at download page the which should fix this bug. In short, there was confusion between the capacity of a vector and the size. I think I've got it all cleanedup now.

- Barry