common: Intentionally leak logger instance to fix hanging on Windows

[rillomas]

Overview

Added workaround for #22142. There are three points in this PR:

• Intentional leak of logger instance
  • ~common_log() called at DLL teardown phase was causing hanging on Windows. DLL teardown phase seems to be a fragile timing to do system calls like mutex lock, cond notify, thread join, etc. which did not provide sane results. We are working around this by intentionally leaking the logger instance to skip cleanup.
• Using static array's instead of std::vector in logger
  • We were seeing crashes on Linux when logger thread outlived the std::vector teardown, causing the thread to touch released items on std::vector. Using static arrays prevents this.
• Calling common_log_free at test-log
  • Even if we skipped the logger destructor, we were still seeing hangs on Windows after adding common_log_flush. This seemed like a timing issue where the OS is running DLL teardown while the runtime tries to start the logger thread asynchronously (which was started by common_log_flush). We added an explicit cleanup in the end of the unit test to avoid this.

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: YES (Copilot GPT5.4 medium). Used for issue analysis and solution recommendation.

[ggerganov]

Does not seem to work - the tests are failing

[rillomas]

Let me have a look again.

[rillomas]

I've fixed the crashing on Linux. It seems like g_col being a vector was causing the heap to get freed at teardown phase while the logger thread is running, causing the crash. Previously the common_log destructor was (presumably) joining the logger thread first assuring g_col was never touched after release.

[rillomas]

Seems like even if we skip the logger's destruction, calling common_log_flush just before the program exits will cause hanging in the same way. It looks like a timing issue where the OS tries to clean the threads and the logger tries to run the logger thread because the hanging goes away when I add printf which changes timing.

I guess I'll just remove the intentional leaking and fix the unit test to call common_log_free since we'll need it anyway, and it's safer to call it from the app rather than during DLL teardown. Forgot that the hanging was happening on other apps so I'll need to keep the intentional leaking. I'll also need the common_log_free in the unit test.