log: properly copy fields for old style logging
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)