do not use global ctor/dtor for test params

[bratpiorka]

Do not use global constructor/destructors for test params.

Description

Currently, all provider and pool tests use parameters created during the instantiation phase, with automatic destructors called upon program exit. The problem occurs when the creation of some parameters requires our global base allocator (in the case for the Disjoint Pool in the C version - not merged yet). In this scenario, the global base allocator's free() function could be called after the deletion of the entire global base allocator, because we cannot guarantee the correct order of destructors. Additionally, in the failing scenario, the base allocator's debug checks will report memory leaks.

Checklist

• Code compiles without errors locally
• All tests pass locally
• CI workflows execute properly

[vinser52]

Currently, all provider and pool tests use parameters created during the instantiation phase, with automatic destructors called upon program exit. The problem occurs when the creation of some parameters requires our global base allocator (in the case for the Disjoint Pool in the C version - not merged yet). In this scenario, the global base allocator's free() function could be called after the deletion of the entire global base allocator, because we cannot guarantee the correct order of destructors. Additionally, in the failing scenario, the base allocator's debug checks will report memory leaks.

Does it mean that in real use cases, the same problem exists? I mean if some shared library (e.g. UR adaptor) will create disjoint pool params in the library ctor than we have the same issue as described?

[bratpiorka]

Does it mean that in real use cases, the same problem exists? I mean if some shared library (e.g. UR adaptor) will create disjoint pool params in the library ctor than we have the same issue as described?

library ctor should be fine. The real problem is with global ctors/dtors like here: https://github.com/oneapi-src/unified-memory-framework/pull/1055/files#diff-0884623826c0b9a057c7517f627f3f2f96062c7b14ff570599a115e46a2dd526L246

What I see on Windows is that the base alloc is destroyed before the global object destructors are called and because of this we see mem leaks in base alloc

[PatKamin]

Looks good