Implement cpuinfo_deinitialize() to free heap-allocated globals

[crvineeth97]

Currently cpuinfo_deinitialize() is a no-op stub. Applications that dynamically load and unload libraries using cpuinfo (e.g., ONNX Runtime as a DLL on Windows, or as a shared library via dlopen/dlclose on Linux) leave orphaned heap allocations when the library is unloaded mid-process. These are flagged as memory leaks by tools such as App Verifier and Valgrind.

This PR implements cleanup for all heap-allocated globals: processors, cores, clusters, packages, caches, and uarch info. Platform-specific details:

• Windows: Uses HeapFree to match HeapAlloc allocations. Cleanup is guarded by InitOnceExecuteOnce for thread safety.
• ARM64 Windows: Caches are freed as a single contiguous block, matching the allocation pattern in init-by-logical-sys-info.c.
• Linux (x86/x86_64/RISC-V), macOS, FreeBSD: Uses free() to match calloc allocations. Cleanup is guarded by pthread_once for thread safety.
• ARM Linux, Emscripten: cpuinfo_deinitialize() is a no-op on these platforms because they use static storage for some globals (packages, L3 cache) that cannot be safely freed.

Cleanup is idempotent, meaning that calling cpuinfo_deinitialize() multiple times is safe.

Also fixes a minor existing leak of processor_infos in the x86 Windows init cleanup path.

Related issues

• pytorch/cpuinfo#150
• microsoft/onnxruntime#16117
• microsoft/onnxruntime#23762

[meta-cla]

Hi @crvineeth97!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[meta-cla]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

[crvineeth97]

Hi @fbarchard @malfet @GregoryComer
Requesting your reviews on this PR. Thank you!

[malfet]

In principle it sounds great, but I think it's better to move the portions for de-init next to respective allocation routines?

[crvineeth97]

The init and deinit guards are reset at the end of the deinitialize function so that if a DLL loads, unloads and then loads again, it can initialize if required.

The deinit tests I added in the previous commit were incorrect since the ABI doesn't allow checking the various variables when cpuinfo_is_initialized is false. The init.cc tests sufficiently test the guard reset since each test does init and deinit

@fbarchard @malfet @GregoryComer

[crvineeth97]

@malfet @fbarchard @GregoryComer May I please get a review for this?

[crvineeth97]

Hi @malfet @fbarchard @GregoryComer, I have a pending pull request in the onnxruntime repo (microsoft/onnxruntime#28245) that depends on this PR. I would greatly appreciate your reviews.

[GregoryComer]

This overall looks reasonable. Given that the changes are mostly gated to the new deinit functions, it should be relatively safe. One request - can you add some tests that cover de-init and then re-init? It would be good to have regression tests to make sure that things function correctly across multiple re-init cycles.

[crvineeth97]

This overall looks reasonable. Given that the changes are mostly gated to the new deinit functions, it should be relatively safe. One request - can you add some tests that cover de-init and then re-init? It would be good to have regression tests to make sure that things function correctly across multiple re-init cycles.

Thank you! The existing init.cc tests already implicitly exercise deinit → re-init cycles and that's the reason why I had to add the reinit in the first place. Each of the ~30 test cases calls cpuinfo_initialize() at the start and cpuinfo_deinitialize() at the end, and since GTest runs them sequentially in a single process, every test after the first is effectively a re-init cycle. Is that sufficient?

[GregoryComer]

Thank you! The existing init.cc tests already implicitly exercise deinit → re-init cycles and that's the reason why I had to add the reinit in the first place. Each of the ~30 test cases calls cpuinfo_initialize() at the start and cpuinfo_deinitialize() at the end, and since GTest runs them sequentially in a single process, every test after the first is effectively a re-init cycle. Is that sufficient?

Ah, good point. That should be sufficient, I think. Since I haven't seen any objections from the other reviews and CI is green, I'll go ahead and merge.

[crvineeth97]

Thank you so much! I really appreciate it

[georgthegreat]

This code introduced races in multithread programs.
At the moment tflite itself and two of its dependencies (ruy and pthreadpool) call this deinitialization concurrently without taking care about other usages.

I would suggest reverting this PR.

[crvineeth97]

Hi @georgthegreat, thanks for flagging this, and apologies for the disruption.

We've run this patch in an internal fork of ORT for over a year without issue, because ORT holds a single static CPUIDInfo instance and init/deinit are each effectively called only once over the process lifetime. That context is what motivated the original PR (we were chasing a memory leak), but you're right that I didn't account for other consumers calling deinit concurrently. I should have been more diligent about it.

Rather than reverting, I've opened a follow-up PR: #400. It replaces the pthread_once/INIT_ONCE reset trick with a mutex and adds refcounting, so shared state is only torn down once the last consumer releases it. Concurrent init/deinit across independent users should be safe after that PR. I've also added a stress test modeling the scenario you described.

Please take a look and let me know if this resolves your concern. If the maintainers would still prefer to revert in the meantime, I'm happy to go that route, but I think landing the fix is the better path forward for everyone relying on cpuinfo.

CC: @GregoryComer @malfet

[snnn]

The linked ONNX Runtime issues are for Linux, but, on Linux dlclose is usually a no-op. It simply directly returns and does nothing. So, the load/reload scenario is very rare. I'd rather ignore(or suppress) the valgrind warnings than fighting with them.

On Windows, I made a change to ONNX Runtime that avoid deallocating global object if the process is shutting down, which can avoid a lot of destruction order issues and can cover most user cases. I knew it could leak memory if we keep loading/unloading the onnxruntime.dll. I also added a test case for it to measure how much memory would be leaked for a DLL load/unload: https://github.com/microsoft/onnxruntime/blob/main/onnxruntime/test/shared_lib/dlopen_main.cc#L276 . But, I believed most Windows DLLs have this issue, and I believed it was not worth to get it perfect as most applications did not have this need. If that were really important, people would stop using C++ programs on Linux.