[Bug libstdc++/48750] New: for_each_template_random_access_ed has unbalanced new/delete[]
bugs at sehe dot nl
gcc-bugzilla@gcc.gnu.org
Sun Apr 24 11:46:00 GMT 2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48750
Summary: for_each_template_random_access_ed has unbalanced
new/delete[]
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: bugs@sehe.nl
thread_results is allocated using scalar new, yet deleted with array delete[]
Version of libs (ubuntu package): libstdc++6-4.4-dev through libstdc++6-4.6-dev
Version of compiler: g++ (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5
Also with: g++ (Debian 4.5.2-8) 4.5.2
Snippets:
/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:
delete[] thread_results;
This is unbalanced, and leads to the expected valgrind errors. Attached is a
snippet (originally from
http://stackoverflow.com/questions/5769908/unexpected-segfault-with-gnu-parallelaccumulate)
that will segfault.
I witnessed the segfault went away when fixing the `delete[]` into `delete`.
However, I think it should be evaluated whether the optimized (uninitializing)
allocation of thread_results is safe to do (valgrind keeps reporting
uninitialized memory references even if the attached example doesn't segfault
anymore).
----
I'll attach the sources in 10 minutes due to time restriction and browser
flakiness
More information about the Gcc-bugs
mailing list