[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