User-provided session logging function is not used for every log

[JulienTheron]

Describe the issue

Since ORT 1.17, we have the ability to assign a logging function to the session options.
However, the feature seems to be incomplete as it only affects some logs where it should affect all of them.

To reproduce

Just create a session with a user-defined logging function. While the session is created, you'll notice a lot of logs to the console (the environment's default logger), while some others are passed to the session logging function.

Here's an (incomplete) example:

const Ort::Env env(ORT_LOGGING_LEVEL_VERBOSE);

Ort::SessionOptions options;
Ort::GetApi().SetUserLoggingFunction(options, MyLoggingFunction, MyLoggingFunctionParam);
options.SetLogSeverityLevel(ORT_LOGGING_LEVEL_VERBOSE);

Ort::Session session(env, ModelFilePath, options);

Urgency

Not urgent.

Platform

Windows

OS Version

Windows 11 23H2

ONNX Runtime Installation

Built from Source

ONNX Runtime Version or Commit ID

1.17.3 and 1.18.0 RC

ONNX Runtime API

C++

Architecture

X64

Execution Provider

Default CPU, CUDA, DirectML, TensorRT

Execution Provider Library Version

No response

[Edward Chen]

Many of the log calls that occur even after a session has been created do not go through the session logger. E.g., you can find many uses of LOGS_DEFAULT in the code.

Consider using the Ort::Env constructor which takes a custom logging function to use a custom logger for more of the logs.

onnxruntime/include/onnxruntime/core/session/onnxruntime_cxx_api.h

Lines 703 to 704 in 113aa29

 /// \brief Wraps OrtApi::CreateEnvWithCustomLogger 
 Env(OrtLoggingLevel logging_level, const char* logid, OrtLoggingFunction logging_function, void* logger_param); 

[JulienTheron]

Many of the log calls that occur even after a session has been created do not go through the session logger. E.g., you can find many uses of LOGS_DEFAULT in the code.

Shouldn't that be considered a bug then?

Consider using the Ort::Env constructor which takes a custom logging function to use a custom logger for more of the logs.

That's what we did before 1.17. But having all logs going to the same place can be a mess when you have multiple sessions being used at the same time.

[Edward Chen]

Many of the log calls that occur even after a session has been created do not go through the session logger. E.g., you can find many uses of LOGS_DEFAULT in the code.

Shouldn't that be considered a bug then?

@pranavsharma what do you think?

[Pranav Sharma]

In the Run() function, we create a separate run logger. This is different from the session logger. We may not have access (or difficult to get access) to the run logger in all the places during the Run call. Hence, we resort to using LOGS_DEFAULT. Your case is different. If you've overridden a session with your own logger, it should be used during session init. If not, it's a bug.