On 07.08.2015 9:22, Sebastian Lackner wrote:
However, this does not fully prevent a leak when frequently unloading / reloading a library using OpenMP... sounds a bit like a design flaw to me.
You could keep a list of allocations to fix that if it's really a problem.
On 07.08.2015 08:57, Nikolay Sivov wrote:
On 07.08.2015 9:22, Sebastian Lackner wrote:
However, this does not fully prevent a leak when frequently unloading / reloading a library using OpenMP... sounds a bit like a design flaw to me.
You could keep a list of allocations to fix that if it's really a problem.
Vcomp wouldn't get notifications for loads/unloads of other libraries, and we also don't know which critical sections belong to which library. A list of allocations could only be used to clean up on process exit. If it is really a problem in practice, I would guess that Windows is affected in a similar way.
On 07.08.2015 10:04, Sebastian Lackner wrote:
On 07.08.2015 08:57, Nikolay Sivov wrote:
On 07.08.2015 9:22, Sebastian Lackner wrote:
However, this does not fully prevent a leak when frequently unloading / reloading a library using OpenMP... sounds a bit like a design flaw to me.
You could keep a list of allocations to fix that if it's really a problem.
Vcomp wouldn't get notifications for loads/unloads of other libraries, and we also don't know which critical sections belong to which library. A list of allocations could only be used to clean up on process exit. If it is really a problem in practice, I would guess that Windows is affected in a similar way.
Is it possible it allocates one section per thread or something like that? E.g. what do two consecutive _vcomp_enter_critsect() calls return for NULL input, is it same pointer every time for example?
On 07.08.2015 09:13, Nikolay Sivov wrote:
On 07.08.2015 10:04, Sebastian Lackner wrote:
On 07.08.2015 08:57, Nikolay Sivov wrote:
On 07.08.2015 9:22, Sebastian Lackner wrote:
However, this does not fully prevent a leak when frequently unloading / reloading a library using OpenMP... sounds a bit like a design flaw to me.
You could keep a list of allocations to fix that if it's really a problem.
Vcomp wouldn't get notifications for loads/unloads of other libraries, and we also don't know which critical sections belong to which library. A list of allocations could only be used to clean up on process exit. If it is really a problem in practice, I would guess that Windows is affected in a similar way.
Is it possible it allocates one section per thread or something like that? E.g. what do two consecutive _vcomp_enter_critsect() calls return for NULL input, is it same pointer every time for example?
No, it returns a different pointer each time. It also returns a new pointer when calling _vcomp_enter_critsect() after the critical section was manually set to zero. Different critical sections are necessary because all "#pragma omp critical" regions should be independent, except they have the same name (then the compiler would use the same static variable).
-
Nikolay Sivov -
Sebastian Lackner