Unexpected segfault with __gnu_parallel::accumulate
This is really confusing me, I would appreciate if anyone could help me out.
(EDIT: thought it was a templated problem, I was mistaken with this)
I want to add multiple copies of the following class with gnu's parallelised accumulate algorithm (stored in #include <parallel/numeric>
)
The class deliberately doesn't do much, I don't think this is a thread collision problem?
template<class T>
class NaturalParameters
{
public:
typedef typename std::vector<T>::iterator iterator;
NaturalParameters()
: m_data(2) //vector with two zeros
{ }
typename std::vector<T>::const_iterator
begin() const
{
return m_data.begin();
}
typename std::vector<T>::const_iterator
end() const
{
return m_data.end();
}
NaturalParameters<T>&
operator+=(const NaturalParameters<T>& other)
{
//do something
return *this;
}
private:
std::vector<T> m_data;
};
template<class T>
inline
NaturalParameters<T>
operator+(const NaturalParameters<T>& a, const NaturalParameters<T>& b)
{
NaturalParameters<T> tmp = a;
return tmp+=b;
}
I then run it
int
main (int ac, char **av)
{
std::vector<NaturalParameters<double> > NP(1000);
NaturalParameters<double> init;
//the following segfaults
NaturalParameters<double> NP2 = __gnu_parallel::accumulate(NP.begin(), NP.end(), init );
//The following runs fine
//NaturalParameters<double> NP2 = std::accumulate(NP.begin(), NP.end(), init );
}
This really confuses me - I have no idea what the problem is.
I'm using g++ 4.4.5 and compiling with g++ gnu_parallel.cpp -g -fopenmp
EDIT:
Note that this works: (999 elements rather than 1000)
for(size_t i=0;i<1000;++i){
std::vector<NaturalParameters> ChildrenNP(999);
NaturalParameters<double> init;
NaturalParameters<double> NP = __gnu_parallel::accumulate(ChildrenNP.begin(), ChildrenNP.end(), init );
//NaturalParameters<double> NP = std::accumulate(ChildrenNP.begin(), ChildrenNP.end(), init );
}
The backtrace is:
Program received signal SIGSEGV, Segmentation fault.
__libc_free (mem=0x12af1) at malloc.c:3709
3709 malloc.c: No such file or directory.
in malloc.c
(gdb) backtrace
#0 __libc_free (mem=0x12af1) at malloc.c:3709
#1 0x00000000004024f8 in __gnu_cxx::new_allocator<double>::deallocate (this=0x614518, __p=0x12af1) at /usr/include/c++/4.4/ext/new_allocator.h:95
#2 0x0000000000401f0a in std::_Vector_base<double, std::allocator<double> >::_M_deallocate (this=0x614518, __p=0x12af1, __n=18446744073709542049) at /usr/include/c++/4.4/bits/stl_vector.h:146
#3 0x00000000004017b9 in std::_Vector_base<double开发者_开发知识库, std::allocator<double> >::~_Vector_base (this=0x614518, __in_chrg=<value optimized out>) at /usr/include/c++/4.4/bits/stl_vector.h:132
#4 0x00000000004013b9 in std::vector<double, std::allocator<double> >::~vector (this=0x614518, __in_chrg=<value optimized out>) at /usr/include/c++/4.4/bits/stl_vector.h:313
#5 0x00000000004012b8 in NaturalParameters<double>::~NaturalParameters (this=0x614518, __in_chrg=<value optimized out>) at gnu_parallel.cpp:10
#6 0x00000000004023e7 in __gnu_parallel::for_each_template_random_access_ed<__gnu_cxx::__normal_iterator<NaturalParameters<double>*, std::vector<NaturalParameters<double>, std::allocator<NaturalParameters<double> > > >, __gnu_parallel::nothing, __gnu_parallel::accumulate_selector<__gnu_cxx::__normal_iterator<NaturalParameters<double>*, std::vector<NaturalParameters<double>, std::allocator<NaturalParameters<double> > > > >, __gnu_parallel::accumulate_binop_reduct<__gnu_parallel::plus<NaturalParameters<double>, NaturalParameters<double> > >, NaturalParameters<double> > (begin=..., end=..., o=..., f=..., r=...,
base=..., output=..., bound=-1) at /usr/include/c++/4.4/parallel/par_loop.h:127
#7 0x0000000000401d70 in std::__parallel::accumulate_switch<__gnu_cxx::__normal_iterator<NaturalParameters<double>*, std::vector<NaturalParameters<double>, std::allocator<NaturalParameters<double> > > >, NaturalParameters<double>, __gnu_parallel::plus<NaturalParameters<double>, NaturalParameters<double> > > (begin=..., end=..., init=..., binary_op=..., parallelism_tag=__gnu_parallel::parallel_unbalanced)
at /usr/include/c++/4.4/parallel/numeric:99
#8 0x0000000000401655 in std::__parallel::accumulate<__gnu_cxx::__normal_iterator<NaturalParameters<double>*, std::vector<NaturalParameters<double>, std::allocator<NaturalParameters<double> > > >, NaturalParameters<double> > (begin=..., end=..., init=...) at /usr/include/c++/4.4/parallel/numeric:139
#9 0x0000000000400e2c in main (ac=1, av=0x7fffffffe188) at gnu_parallel.cpp:59
This definitely looks like a bug in libstdc++:
/usr/include/c++/4.4/parallel/par_loop.h:87
# pragma omp single
{
num_threads = omp_get_num_threads();
thread_results = static_cast<Result*>(
::operator new(num_threads * sizeof(Result)));
constructed = new bool[num_threads];
}
But line 127 deletes it with
delete[] thread_results;
_Apparently, the construction of thread_results was optimized at one stage, but the deletion statement was never updated to reflect this. The optimization makes sense over just newing up the array (new Result[num_threads]) because it avoids constructing the elements._
Fixing that to
delete thread_results;
removes the bug. You will want to report this to the gnu devs.
You might still have some residu problems with the threadsafety of std::__cxx1998::vector::operator=. You can see what I mean by using valgrind. However, it is entirely possible that valgrind reports a fasle positive there.
I just tested the other way around: when using new Result[num_threads]
with delete[]
(instead of the optimized version in the GNU source) you'll get a clean valgrind run all the way. I'm pretty sure this will be a false positive, but I'd sure mention it to the GNU devs while you report the bug.
Well, this is threading. Threading is hard. Even with gomp/parallel extensions. Try helgrind (valgrind --tool=helgrind ./t
). The output is so large... SO won't let me paste it in here :)
精彩评论