Skip to content

log: properly copy fields for old style logging

Christian Kellner requested to merge i119 into master

When bolt native logging is used, the bolt_logv functions, as the central logging point, will hold a BoltLogCtx on the stack which is initialized with the necessary and optional fields. The actual logger function (daemon_logger) will try to find that BoltLogCtx (via the special BOLT_LOG_CTX_KEY key). If that is not found, a new BoltLogCtx is created and then initialized with the fields provided by the logger function. The previous code did reserve three fields for the special fields MESSAGE, GLIB_DOMAIN and PRIORITY, but did not properly initialize those fields, resulting in a crash when those fields were accessed:

  #0  0x00007ffff7bb4895 in __strlen_avx2 () from target:/lib64/libc.so.6
  #1  0x00007ffff7ed1893 in g_log_writer_journald () from target:/lib64/libglib-2.0.so.0
  #2  0x000055555556cc5f in bolt_log_journal (ctx=ctx@entry=0x5555555ee980, log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, flags=flags@entry=0) at ../boltd/bolt-log.c:551
  #3  0x00005555555607a8 in daemon_logger (level=G_LOG_LEVEL_CRITICAL, fields=<optimized out>, n_fields=<optimized out>, user_data=<optimized out>) at ../boltd/bolt-daemon.c:82
  #4  0x00007ffff7ed0047 in g_log_structured_array () from target:/lib64/libglib-2.0.so.0
  #5  0x00007ffff7ed0491 in g_log_default_handler () from target:/lib64/libglib-2.0.so.0
  #6  0x00007ffff7ed06df in g_logv () from target:/lib64/libglib-2.0.so.0
  #7  0x00007ffff7ed08d3 in g_log () from target:/lib64/libglib-2.0.so.0
  #8  0x0000555555572362 in bolt_domain_get_security (domain=0x0) at ../boltd/bolt-domain.c:266

The fix is to reserve the fields only on-demand and also properly initializing them by copying the provided field(s).

Closes #119 (closed)

Edited by Christian Kellner

Merge request reports