Hi Harald! Unfortunately, your change [1] breaks some osmo-* projects. I am getting the following segfault with OsmoMSC: [1] https://git.osmocom.org/libosmocore/commit/?id=b3f94eb39e19366c3458643ee329a... [1] https://gerrit.osmocom.org/#/c/libosmocore/+/14361/ ERROR: osmo_log_info == NULL! You must call log_init() before using logging in log_check_level()! Assert failed osmo_log_info logging.c:184 backtrace() returned 10 addresses /usr/local/lib/libosmocore.so.12(+0x16f6b) [0x7ffff72dff6b] /usr/local/lib/libosmocore.so.12(osmo_panic+0xc0) [0x7ffff72dff20] /usr/local/lib/libosmocore.so.12(+0x14487) [0x7ffff72dd487] /usr/local/lib/libosmocore.so.12(log_check_level+0x1a) [0x7ffff72de82a] /usr/local/lib/libosmocore.so.12(osmo_fsm_register+0xef) [0x7ffff72d81bf] /home/wmn/osmocom/osmo-msc/tests/msc_vlr/msc_vlr_test_ss() [0x692e03] /home/wmn/osmocom/osmo-msc/tests/msc_vlr/msc_vlr_test_ss() [0x9b6aad] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x7ffff595fed5] /home/wmn/osmocom/osmo-msc/tests/msc_vlr/msc_vlr_test_ss() [0x4215cc] gdb-peda$ bt #0 0x00007ffff5974c37 in __GI_raise (sig=sig@entry=0x6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff5978028 in __GI_abort () at abort.c:89 #2 0x00007ffff72dff25 in osmo_panic_default (args=0x7fffffffda48, fmt=0x7ffff72e8cb9 "Assert failed %s %s:%d\n") at panic.c:49 #3 osmo_panic (fmt=fmt@entry=0x7ffff72e8cb9 "Assert failed %s %s:%d\n") at panic.c:84 #4 0x00007ffff72dd487 in assert_loginfo (src=<optimized out>) at logging.c:184 #5 0x00007ffff72de82a in log_check_level (subsys=subsys@entry=0xffffffff, level=level@entry=0x7) at logging.c:1033 #6 0x00007ffff72d81bf in osmo_fsm_register (fsm=0xcc6c20 <msc_a_fsm>) at fsm.c:261 #7 0x0000000000692e03 in msc_a_fsm_init () at msc_a.c:1003 #8 0x00000000009b6aad in __libc_csu_init () #9 0x00007ffff595fed5 in __libc_start_main (main=0x517540 <main>, argc=0x1, argv=0x7fffffffdcb8, init=0x9b6a60 <__libc_csu_init>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdca8) at libc-start.c:246 #10 0x00000000004215cc in _start () As can be seen, this happens when we register 'msc_a' FSM, which of course has .allstate_event_mask == 0x00, and dummy .allstate_action == msc_a_fsm_allstate_action(), which basically does nothing. The registration happens even before the main() is called, since we use '__attribute__((constructor))', and logging is not yet initialized at that time. We need to fix the FSM definition, but right now I think we have no other way than reverting [1]. With best regards, Vadim Yanitskiy.