Memory Leak with ortcreateenv

[qw2208]

Describe the bug
I'm trying to integrate the onnxruntime into our framework. However, we got memory leak for ortcreateenv.

System information

• OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Windows 2016 server.
• ONNX Runtime installed from (source or binary): source. Offline build.

With onnxruntime_cxx_api.h, we wrapped Ort::Env as a private member of our class and noticed it was a singleton.
Build my project with cmakelists:
target_link_libraries(cmftk PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/../installed/onnx/lib/onnxruntime.lib)
Even I do not create the Ort::Env, I still got the memory leaks.

[snnn]

Could you please share me more information? We have memory leak check in our CI build, I believe there isn't any memory leak in normal use cases. But, if you didn't create the env, you won't be able to delete it, and you will absolutely see memory leaks, they are from protobuf, which allocated the memory when onnxruntime.dll get loaded.

[qw2208]

Thanks. I will close this issue and recheck my projects.

[yelu]

Could you please share me more information? We have memory leak check in our CI build, I believe there isn't any memory leak in normal use cases. But, if you didn't create the env, you won't be able to delete it, and you will absolutely see memory leaks, they are from protobuf, which allocated the memory when onnxruntime.dll get loaded.

Did you mean that “if my executable links over onnx shared lib, I have to create env once? Otherwise, the memory leak will happen?” If so, I don't think it is reasonable.

The scenario is: the executable links onnx shared lib. But we may not run into the path to load any onnx model in the lifetime of the executable. It depends on the configuration.

[snnn]

Correct.

[yelu]

Correct.

Then I think this is not the right design for onnxruntime.dll. We also tried that, onnxruntime.dll didn't support delay loading(/DELAYLOAD switch in MSBuild). It means some global resource is allocated during startup no matter onnx is requested or not.

The result is: there is no way to avoid memory leak if I don't load any onnx model, once I link against onnxruntime.dll. I think this should be fixed or improved in onnx. What do you think?

[snnn]

How did you load onnxruntime.dll? At link time or by using Loadlibrary at runtime?

If it's link time, I don't think it's memory leak. Because you only allocate the memory once, it won't hurt you much. Usually we only concern the allocations in repeated calls.

[snnn]

However, as you suggested, we should try to reduce memory footprint in case of people just load this Dll but don't use it.

[yelu]

How did you load onnxruntime.dll? At link time or by using Loadlibrary at runtime?

If it's link time, I don't think it's memory leak. Because you only allocate the memory once, it won't hurt you much. Usually we only concern the allocations in repeated calls.

Ok. Let me clarify this. We link against onnxruntime.dll at link time(Not calling LoadLibrary at runtime). In certain code path, no onnx model needs to be loaded. In this case, no function in onnx runtime gets called by our code explicitly. Then memory leak is experienced.

[snnn]

Hi @yelu,

But it only happen once, for each process, It won't cause memory usage growing.

[qw2208]

Hi @snnn ,
Thanks for the reply. Even though it might not cause dramatic danger, memory leak is not a good thing, is it?
I think It's a necessary requirement.

[pranavsharma]

This is not really a memory leak. As it has been stated before, the memory usage is not growing with time or with each request. The protocol buffer library is doing a one-time constant allocation and it stays there. You do expect your app to call into the DLL under some condition, don't you? And this condition will become true at least once during the lifecycle of your app, yes? If so, I don't quite understand the concern. Most likely I'm missing something here?

[qw2208]

Thanks @pranavsharma.
Yes, I do understand your points. But you could not assume the users will call into the dll. For example, what if I just support onnxruntime as a part of my framework, though it might be not that dangerous.

[pranavsharma]

I suggest you use dlopen/LoadLibrary to load the DLL when there's a need to call into the DLL. If there's no need, you don't pay the cost of the one time constant protobuf initialization and associated memory because from what you're saying it looks like this is going to be an infrequent event. I hope this addresses your concerns. Feel free to re-open.