URGENT: OsmoMSC is broken by the recent changes in libosmocore

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Vadim Yanitskiy axilirator at gmail.com
Sat Jun 15 16:45:13 UTC 2019


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=b3f94eb39e19366c3458643ee329a73155d46ff8
[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 at 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 at 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 at entry=0xffffffff, level=level at 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.



More information about the OpenBSC mailing list