Implement cpuinfo_deinitialize() to free heap-allocated globals#387
Implement cpuinfo_deinitialize() to free heap-allocated globals#387crvineeth97 wants to merge 3 commits intopytorch:mainfrom
cpuinfo_deinitialize() to free heap-allocated globals#387Conversation
|
Hi @crvineeth97! Thank you for your pull request and welcome to our community. Action RequiredIn 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. ProcessIn 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 If you have received this in error or have any questions, please contact us at cla@meta.com. 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 <223556219+Copilot@users.noreply.github.com>
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks! |
crvineeth97
force-pushed
the
vchelur/add-cpuinfo-deinitialize
branch
from
831e1bb to
8ff94bd
Compare
|
Hi @fbarchard @malfet @GregoryComer |
malfet
left a comment
malfet
left a comment
There was a problem hiding this comment.
In principle it sounds great, but I think it's better to move the portions for de-init next to respective allocation routines?
|
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 |
2 participants
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 viadlopen/dlcloseon 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:
HeapFreeto matchHeapAllocallocations. Cleanup is guarded byInitOnceExecuteOncefor thread safety.init-by-logical-sys-info.c.free()to matchcallocallocations. Cleanup is guarded bypthread_oncefor thread safety.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_infosin the x86 Windows init cleanup path.Related issues