a confusing core dump

[ZaneHsueh]

sorry to disturb， but there's one core dump that draws me crazy. Here's the situation at the very beginning, it seems to be something wrong in the function of startPollingThread.

terminate called after throwing an instance of 'fmt::v9::format_error'
what(): unmatched '}' in format string
Aborted (core dumped)

(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007f8d973487f1 in __GI_abort () at abort.c:79
#2 0x00007f8d9799d957 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007f8d979a3ae6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007f8d979a3b21 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007f8d979a3d54 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007f8d97cea715 in fmt::v9::detail::throw_format_error(char const*) ()
from ../../../lib/libark.so
#7 0x00007f8d97d003cb in void fmt::v9::detail::vformat_to(fmt::v9::detail::buffer&, fmt::v9::basic_string_view, fmt::v9::detail::vformat_args::type, fmt::v9::detail::locale_ref) ()
from ../../../lib/libark.so
#8 0x00007f8d97ce67d1 in fmtlogDetailT<0>::poll(bool) [clone .constprop.159] ()
from ../../../lib/libark.so
#9 0x00007f8d97ce74ea in std:🧵:_State_impl<std:🧵:_Invoker<std::tuple<fmtlogDetailT<0>::startPollingThread(long)::{lambda()https://github.com/MengRao/fmtlog/issues/1}> > >::_M_run() () from ../../../lib/libark.so
#10 0x00007f8d979ce6df in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#11 0x00007f8d985ee6db in start_thread (arg=0x7f8d55372700) at pthread_create.c:463
#12 0x00007f8d9742961f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

the problem doesn't occur every time, and probability of occurrence is about 1/50, thank you so much if you can give a hand to figure out what happened. Here's the calling

std::string &&filename = fmt::format("{}/{}_{}.log", dir, _name, curDate);
fmtlog::startPollingThread(1);
fmtlog::setLogLevel(fmtlog::DBG);
fmtlog::setLogFile(filename.c_str(), false);
fmtlog::setHeaderPattern("[{l}]<{YmdHMSF}>({t}-{s})$");
fmtlog::setLogCB(glb::log_callback, fmtlog::DBG);

[MengRao]

can you try moving fmtlog::startPollingThread(1) to the end of the code block?

[MengRao]

Normally, setLogFile and setHeaderPattern should be called in the same thread with polling. In the case of using startPollingThread()，those init functions should be called at first.

[ZaneHsueh]

Thank u so much for reply, I'll have a try. But I'm not sure if the problem has solved for the core dump doesn't occur each time. Wonder if it is too rude to ask u that the method u gave is a certain one or a guess one. Could u plz let me know, thank u.

[MengRao]

If you use setLogFile/setHeaderPattern after startPollingThread(), there will be race condition.

[ZaneHsueh]

get it, thank u and solute. one more question, plz, wanna make sure that is it allowed to do some log at the very beginning, I mean, before any init funcs and before startPollingThread?

[MengRao]

Yes，it's allowed.

[ZaneHsueh]

thx a lot, the problem has been solved! but there's a further question, just need to make sure if the calling is correct. I read about the usage of startPollingThread in README.md and tests, but wonder is it allowed to call fmtlog::poll() before fmtlog::startPollingThread just like the code below:

    logi("process start...");
    fmtlog::poll();

    std::string &&filename = fmt::format("{}/{}_{}.log", dir, _name, curDate);
    fmtlog::setHeaderPattern("[{l}]<{YmdHMSF}>({t}-{s})$");
    fmtlog::setLogCB(glb::log_callback, fmtlog::DBG);
    fmtlog::setLogFile(filename.c_str(), false);
    fmtlog::setLogLevel(fmtlog::DBG);
    fmtlog::poll();

    fmtlog::startPollingThread(1);

Is it recommended?

[MengRao]

there's no problem with it.