------- Comment #1 from jakub at gcc dot gnu dot org 2008-05-23 17:03 -------
This is not a memory leak, just misunderstanding what valgrind is reporting.
Memory still reachable at exit time is not a bug, all memory is freed by exit.
Some libraries are instrumented with hooks that at exit time can be called from
memory allocation checker (valgrind, mtrace, ...), e.g. libc, but in some cases
this isn't possible at all and only very few libraries are instrumented that
way.
Memory leak is when something hasn't been freed, but isn't reachable anymore.
The rest are just potential problems that you can analyze.
In libgomp case, most of the allocations still reachable at exit time fall into
the category where they really can't be freed. Remember the requirement
spelled in threadprivate directive description, if the number of threads is the
same between two consecutive parallel regions and two of the ICVs didn't
change, then
threadprivate vars must be preserved. This means a thread pool must be live
whenever there was some parallel region, with the number of threads from the
last parallel region. For that you need some malloced control data structures
and each thread has its TLS allocaed too.
--
jakub at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Keywords| |openmp
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36298
