Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
16 Views

Assertion ref_count race detected

Jump to solution
Can somebody please help me? I'm getting this assertion:

Assertion !(prefix().extra_state & es_ref_count_active) failed on line 211 of file ../../src
/tbb/task.cpp
Detailed description: ref_count race detected


tbb40_20120613oss, boost_1_49_0, Visual Studio 2010, Windows 7 SP1, Core i7 860

[cpp]int main(int argc, char *argv[]) { tbb::parallel_for (0, 2000000000, [](int p_task_id) { if (p_task_id==0) { int sum = 0; boost::thread user_thread([∑] { for (int i=0; i<10000; ++i) for (int j=0; j<100000; ++j) sum += (i*j)%7; }); std::cout << sum; } else { if (p_task_id%1000000==0) std::cerr << "."; } }); }[/cpp]

EDIT:
I made sure that only one thread is created inside parallel_for. The same assertion still shows up.
EDIT:
sum is now declared inside user_thread. Still the same assertion.
EDIT:
undo my last change. I was wrong. moving sum into user_thread fixed the problem.
0 Kudos

Accepted Solutions
Highlighted
Employee
16 Views
Another race seems on 'sum' because AFAIU user_thread is not a blocking call which creates thread and waits on it. So, the thread recieves reference to 'sum' and writes to it while the scope where it was defined is finished and the 'sum' is destroyed... which can easily lead to memory corruption in tbb task sceduler reporting the problem.

View solution in original post

0 Kudos
3 Replies
Highlighted
16 Views
Hello, thanks for report.
I have a question: how many boost threads are created inside parallel_for? According to the code it should be 1-8 in random way sincefirst_task variable is shared and not guarded.
--Vladimir
0 Kudos
Highlighted
Black Belt
16 Views
To get rid of the red herring (presumably), make first_task an atomic and use compare_and_swap().
0 Kudos
Highlighted
Employee
17 Views
Another race seems on 'sum' because AFAIU user_thread is not a blocking call which creates thread and waits on it. So, the thread recieves reference to 'sum' and writes to it while the scope where it was defined is finished and the 'sum' is destroyed... which can easily lead to memory corruption in tbb task sceduler reporting the problem.

View solution in original post

0 Kudos