say: fix crash say_logger_init on invalid configuration
say_logger_init() zeroes the default logger object (log_default) before proceeding to logging subsystem configuration. If configuration fails for some reason (e.g. error opening the log file), the default logger will be left uninitialized, and we will crash trying to print the error to the console: #0 0x564065001af5 in print_backtrace+9 #1 0x564064f0b17f in _ZL12sig_fatal_cbi+e2 #2 0x7ff94519f0c0 in __restore_rt+0 #3 (nil) in +0 #4 0x564064ffc399 in say_default+d2 #5 0x564065011c37 in _ZNK11SystemError3logEv+6d #6 0x5640650117be in exception_log+3d #7 0x564064ff9750 in error_log+1d #8 0x564064ff9847 in diag_log+50 #9 0x564064ffab9b in say_logger_init+22a #10 0x564064f0bffb in load_cfg+69a #11 0x564064fd2f49 in _ZL13lbox_cfg_loadP9lua_State+12 #12 0x56406502258b in lj_BC_FUNCC+34 #13 0x564065045103 in lua_pcall+18e #14 0x564064fed733 in luaT_call+29 #15 0x564064fe5536 in lua_main+b9 #16 0x564064fe5d74 in run_script_f+7b5 #17 0x564064f0aef4 in _ZL16fiber_cxx_invokePFiP13__va_list_tagES0_+1e #18 0x564064fff4e5 in fiber_loop+82 #19 0x5640651a123b in coro_init+4c #20 (nil) in +4c Fix this by making say_logger_init() initialize the default logger object first and only assign it to log_default on success. See #3048
Loading
Please register or sign in to comment