Implement `cpuinfo_deinitialize()` to free heap-allocated globals by crvineeth97 · Pull Request #387 · pytorch/cpuinfo

crvineeth97 · 2026-05-05T01:05:29Z

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

meta-cla · 2026-05-05T01:05:35Z

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 [email protected]. Thanks!

Bump pytorch/cpuinfo to crvineeth97/cpuinfo@df8c6a8 which implements cpuinfo_deinitialize() to properly free heap-allocated globals. This prevents memory leak reports from App Verifier, Valgrind, and sanitizers when ORT is dynamically loaded/unloaded. ORT integration: - Add CPUIDInfo::ShutDown() which calls cpuinfo_deinitialize() - Call ShutdownCpuInfo() from DllMain on DLL_PROCESS_DETACH - In memleak-check builds, also call shutdown during process termination The cpuinfo bump also includes upstream fixes that make three ORT patches redundant (removed): - patch_vcpkg_arm64ec_support.patch (pytorch/cpuinfo#324) - win_arm_fp16_detection_fallback.patch (pytorch/cpuinfo#348) - 0001-Add-implementation-for-cpuinfo_deinitialize.patch The patch_cpuinfo_h_for_arm64ec.patch is retained as it is not yet upstream in cpuinfo. Related: pytorch/cpuinfo#150, pytorch/cpuinfo#387 Co-authored-by: Copilot <[email protected]>

meta-cla · 2026-05-05T18:24:35Z

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

crvineeth97 · 2026-05-06T20:47:57Z

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 · 2026-05-08T23:32:47Z

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 · 2026-06-03T16:44:45Z

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

crvineeth97 · 2026-06-11T07:13:40Z

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 · 2026-06-12T00:07:44Z

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 · 2026-06-12T00:13:23Z

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 · 2026-06-12T00:21:47Z

Thank you so much! I really appreciate it

Bump pytorch/cpuinfo to crvineeth97/cpuinfo@df8c6a8 which implements cpuinfo_deinitialize() to properly free heap-allocated globals. This prevents memory leak reports from App Verifier, Valgrind, and sanitizers when ORT is dynamically loaded/unloaded. ORT integration: - Add CPUIDInfo::ShutDown() which calls cpuinfo_deinitialize() - Call ShutdownCpuInfo() from DllMain on DLL_PROCESS_DETACH - In memleak-check builds, also call shutdown during process termination The cpuinfo bump also includes upstream fixes that make three ORT patches redundant (removed): - patch_vcpkg_arm64ec_support.patch (pytorch/cpuinfo#324) - win_arm_fp16_detection_fallback.patch (pytorch/cpuinfo#348) - 0001-Add-implementation-for-cpuinfo_deinitialize.patch The patch_cpuinfo_h_for_arm64ec.patch is retained as it is not yet upstream in cpuinfo. Related: pytorch/cpuinfo#150, pytorch/cpuinfo#387 Co-authored-by: Copilot <[email protected]>

Add support for freeing cpuinfo memory

df8c6a8

crvineeth97 mentioned this pull request May 5, 2026

Update cpuinfo to include cpuinfo_deinitialize(), fix QNN ETW logging, GQA underflow, and ep_weight_sharing_ctx_gen build microsoft/onnxruntime#28245

Open

meta-cla Bot added the cla signed label May 5, 2026

Add deinit tests

8ff94bd

crvineeth97 force-pushed the vchelur/add-cpuinfo-deinitialize branch from 831e1bb to 8ff94bd Compare May 6, 2026 18:59

malfet reviewed May 6, 2026

View reviewed changes

Comment thread src/cpuinfo/internal-api.h

malfet requested changes May 6, 2026

View reviewed changes

Comment thread src/init.c Outdated

Move the deinits to respective allocation routines

f94ccaf

crvineeth97 requested a review from malfet May 8, 2026 23:27

Use compound literals for guard resets

52aee9c

GregoryComer approved these changes Jun 11, 2026

View reviewed changes

GregoryComer merged commit 4628dc0 into pytorch:main Jun 12, 2026
12 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement `cpuinfo_deinitialize()` to free heap-allocated globals#387

Implement `cpuinfo_deinitialize()` to free heap-allocated globals#387
GregoryComer merged 4 commits into
pytorch:mainfrom
crvineeth97:vchelur/add-cpuinfo-deinitialize

crvineeth97 commented May 5, 2026

Uh oh!

meta-cla Bot commented May 5, 2026

Uh oh!

meta-cla Bot commented May 5, 2026

Uh oh!

crvineeth97 commented May 6, 2026

Uh oh!

Uh oh!

malfet left a comment

Uh oh!

Uh oh!

crvineeth97 commented May 8, 2026 •

edited

Loading

Uh oh!

crvineeth97 commented Jun 3, 2026

Uh oh!

crvineeth97 commented Jun 11, 2026

Uh oh!

GregoryComer left a comment

Uh oh!

crvineeth97 commented Jun 12, 2026

Uh oh!

GregoryComer commented Jun 12, 2026

Uh oh!

Uh oh!

crvineeth97 commented Jun 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

crvineeth97 commented May 5, 2026

Uh oh!

meta-cla Bot commented May 5, 2026

Action Required

Process

Uh oh!

meta-cla Bot commented May 5, 2026

Uh oh!

crvineeth97 commented May 6, 2026

Uh oh!

Uh oh!

malfet left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

crvineeth97 commented May 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

crvineeth97 commented Jun 3, 2026

Uh oh!

crvineeth97 commented Jun 11, 2026

Uh oh!

GregoryComer left a comment

Choose a reason for hiding this comment

Uh oh!

crvineeth97 commented Jun 12, 2026

Uh oh!

GregoryComer commented Jun 12, 2026

Uh oh!

Uh oh!

crvineeth97 commented Jun 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

crvineeth97 commented May 8, 2026 •

edited

Loading