[Bug c++/48751] New: Incorrect delete[] in c++/4.4/parallel/par_loop.h line 127
t.h.shorrock at gmail dot com
gcc-bugzilla@gcc.gnu.org
Sun Apr 24 12:02:00 GMT 2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48751
Summary: Incorrect delete[] in c++/4.4/parallel/par_loop.h line
127
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: t.h.shorrock@gmail.com
__gnu_parallel::accumulate gives a segfault when accumulating over 1000
elements (but not 999).
This was originally asked as a question on StackOverflow -
http://stackoverflow.com/questions/5769908/unexpected-segfault-with-gnu-parallelaccumulate:
Sehe diagnosed the problem as a bug in 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.
"
SYSTEM
Ubuntu 10-10 on AMD64 dual core.
TO RECREATE:
#include <vector>
#include <parallel/algorithm>
#include <parallel/numeric>
class NaturalParameters
{
public:
NaturalParameters()
: m_data(2) //defualt constructor
{ }
std::vector<double>::const_iterator
begin() const
{
return m_data.begin();
}
std::vector<double>::const_iterator
end() const
{
return m_data.begin();
}
NaturalParameters&
operator+=(const NaturalParameters& other)
{
//do something - well actually ... nothing for the purposes of this bug
report.
return *this;
}
private:
std::vector<double> m_data;
};
inline
NaturalParameters
operator+(const NaturalParameters& a, const NaturalParameters& b)
{
NaturalParameters tmp = a;
return tmp+=b;
}
int
main (int ac, char **av)
{
//This one succeeds
for(size_t i=0;i<1000;++i){
std::vector<NaturalParameters> ChildrenNP(999);
NaturalParameters init;
NaturalParameters NP = __gnu_parallel::accumulate(ChildrenNP.begin(),
ChildrenNP.end(), init );
}
//This one fails with a segfault
for(size_t i=0;i<1000;++i){
std::vector<NaturalParameters> ChildrenNP(1000);
NaturalParameters init;
NaturalParameters NP = __gnu_parallel::accumulate(ChildrenNP.begin(),
ChildrenNP.end(), init );
}
}
Preprocessed file attached
COMMAND:
g++ -v gnu_parallel_bug.cpp -g -fopenmp -Wall -D_GLIBCXX_PARALLEL -save-temps
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.4.4-14ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--disable-werror --with-arch-32=i686 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)
COLLECT_GCC_OPTIONS='-v' '-g' '-fopenmp' '-Wall' '-D_GLIBCXX_PARALLEL'
'-save-temps' '-shared-libgcc' '-mtune=generic' '-pthread'
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/cc1plus -E -quiet -v -D_GNU_SOURCE
-D_REENTRANT -D_GLIBCXX_PARALLEL gnu_parallel_bug.cpp -D_FORTIFY_SOURCE=2
-mtune=generic -Wall -fopenmp -g -fworking-directory -fpch-preprocess
-fstack-protector -o gnu_parallel_bug.ii
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../x86_64-linux-gnu/include"
ignoring nonexistent directory "/usr/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/4.4
/usr/include/c++/4.4/x86_64-linux-gnu
/usr/include/c++/4.4/backward
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/include
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-g' '-fopenmp' '-Wall' '-D_GLIBCXX_PARALLEL'
'-save-temps' '-shared-libgcc' '-mtune=generic' '-pthread'
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/cc1plus -fpreprocessed gnu_parallel_bug.ii
-quiet -dumpbase gnu_parallel_bug.cpp -mtune=generic -auxbase gnu_parallel_bug
-g -Wall -version -fopenmp -fstack-protector -o gnu_parallel_bug.s
GNU C++ (Ubuntu/Linaro 4.4.4-14ubuntu5) version 4.4.5 (x86_64-linux-gnu)
compiled by GNU C version 4.4.5, GMP version 4.3.2, MPFR version 3.0.0-p3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b408a5c1addf39d3fcc1ff19852f1cfe
COLLECT_GCC_OPTIONS='-v' '-g' '-fopenmp' '-Wall' '-D_GLIBCXX_PARALLEL'
'-save-temps' '-shared-libgcc' '-mtune=generic' '-pthread'
as -V -Qy -o gnu_parallel_bug.o gnu_parallel_bug.s
GNU assembler version 2.20.51 (x86_64-linux-gnu) using BFD version (GNU
Binutils for Ubuntu) 2.20.51-system.20100908
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.4.5/:/usr/lib/gcc/x86_64-linux-gnu/4.4.5/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.4.5/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.4.5/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.4.5/:/usr/lib/gcc/x86_64-linux-gnu/4.4.5/:/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../:/lib/:/usr/lib/
Reading specs from /usr/lib/gcc/x86_64-linux-gnu/4.4.5/libgomp.spec
COLLECT_GCC_OPTIONS='-v' '-g' '-fopenmp' '-Wall' '-D_GLIBCXX_PARALLEL'
'-save-temps' '-shared-libgcc' '-mtune=generic' '-pthread'
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/collect2 --build-id --eh-frame-hdr -m
elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 -z
relro /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/crt1.o
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/crtbegin.o
-L/usr/lib/gcc/x86_64-linux-gnu/4.4.5 -L/usr/lib/gcc/x86_64-linux-gnu/4.4.5
-L/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../..
gnu_parallel_bug.o -lstdc++ -lm -lgomp -lgcc_s -lgcc -lpthread -lc -lgcc_s
-lgcc /usr/lib/gcc/x86_64-linux-gnu/4.4.5/crtend.o
/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/crtn.o
Output:
./a.out
Segmentation fault
SEE ALSO:
Additional comment on:
http://stackoverflow.com/questions/5769908/unexpected-segfault-with-gnu-parallelaccumulate
"
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.
"
More information about the Gcc-bugs
mailing list