Memory leak in cpuinfo_x86_linux_init

[jrosdahl]

Describe the issue

When using ONNX Runtime 1.14.1 with a Linux C++ program built with GCC's -fsanitize=leak option (LeakSanitizer AKA LSan) or -fsanitize=address (AddressSanitizer AKA ASan), memory leaks are reported at program exit:

=================================================================
==11753==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 576 byte(s) in 1 object(s) allocated from:
    #0 0x2b11dd429917 in __interceptor_calloc (/path/to/libasan.so.6+0xb4917)
    #1 0x2b11e45064b6 in cpuinfo_x86_linux_init (/path/to/libonnxruntime.so.1.14.1+0x8684b6)

Direct leak of 576 byte(s) in 1 object(s) allocated from:
    #0 0x2b11dd429917 in __interceptor_calloc (/path/to/libasan.so.6+0xb4917)
    #1 0x2b11e4506496 in cpuinfo_x86_linux_init (/path/to/libonnxruntime.so.1.14.1+0x868496)

SUMMARY: AddressSanitizer: 1152 byte(s) leaked in 2 allocation(s).

From code inspection, is seems that the call to cpuinfo_initialize does not seem to have a corresponding call to cpuinfo_deinitialize. On the other hand, cpuinfo_deinitialize doesn't actually free the allocated memory so it wouldn't have helped. Reported in pytorch/cpuinfo#150.

Still, the memory leaks show up as a problem for ONNX Runtime users who run their programs with LeakSanitizer and flag memory leaks as errors in CI pipelines and the like, so it would be great if it could be resolved even if the issue certainly could be considered minor for most users.

To reproduce

1. Create an ONNX Runtime program with GCC's -fsanitize=leak or -fsanitize=address options.
2. Execute it.
3. Check the memory leak report printed to stderr.

I don't have a minimal reproducible example at hand right now, but I can try to make one on request.

Urgency

No response

Platform

Linux

OS Version

CentOS 7.9

ONNX Runtime Installation

Built from Source

ONNX Runtime Version or Commit ID

1.14.1

ONNX Runtime API

C++

Architecture

X64

Execution Provider

Default CPU

Execution Provider Library Version

No response

[snnn]

I will make a quick fix.

[snnn]

It seems not easy. It is related to #15661 . I will talk to the devs in @onnxruntime-mlas team , I suggest adding an initialize function to mlas so that I can call it in Environment::Initialize() function. And the initialization happens after initialize cpuinfo. And the functions in WindowsEnv should return Status instead of use loggers. Callers of the functions can decide when to print out.

[snnn]

If we call cpuinfo_initialize in Environment class's constructor, we can call the cpuinfo_deinitialize in its destructor. Then there will not be any memory leak if cpuinfo_deinitialize works as expected