libcamera: log: Destroy LogCategory instances in a controlled way

The LogCategory instances are constructed on first use as static
variables in accessor functions, following the Meyers singleton pattern.
As a result, their destruction order is not guaranteed. This can cause
issues as the global Logger object, constructed in a similar fashion, is
accessed from the LogCategory destructor and may be destroyed first.

To fix this, keep the same singleton pattern, but allocate the
LogCategory instances dynamically. As they get registered with the
global Logger instance, we can destroy them in the Logger destructor.

This only avoids destruction order issues between LogCategory and
Logger, and doesn't address yet the fact that LOG() calls from
destructors of global objects may access an already destroyed Logger.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chormium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
This commit is contained in:
Laurent Pinchart 2021-05-23 02:51:32 +03:00
parent 2f6b951b75
commit 01e387acb0
2 changed files with 14 additions and 24 deletions

View file

@ -29,7 +29,6 @@ class LogCategory
{
public:
explicit LogCategory(const char *name);
~LogCategory();
const char *name() const { return name_; }
LogSeverity severity() const { return severity_; }
@ -48,8 +47,9 @@ extern const LogCategory &_LOG_CATEGORY(name)();
#define LOG_DEFINE_CATEGORY(name) \
const LogCategory &_LOG_CATEGORY(name)() \
{ \
static LogCategory category(#name); \
return category; \
/* The instance will be deleted by the Logger destructor. */ \
static LogCategory *category = new LogCategory(#name); \
return *category; \
}
class LogMessage