Bug #2924
closedosmo-msc MGCP FSM has no event names
100%
Description
there are no event names registered with the "MGW" fsm, which makes it much harder to understand log output by humans. osmo_fsm has automatic translation from event numbers to human-readable names, please make use of it.
Related issues
Updated by stsp about 6 years ago
The osmo-msc VTY command 'show fsm all' will crash the process if no event names are defined for an FSM:
Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7bc7f09 in vty_out_fsm (vty=0x5555558cdd70, fsm=0x5555557a92a0 <fsm>) at fsm_vty.c:64 64 for (evt_name = fsm->event_names; evt_name->str != NULL; evt_name++) { (gdb) p fsm->event_names $4 = (const struct value_string *) 0x0 (gdb) p fsm $5 = (struct osmo_fsm *) 0x5555557a92a0 <fsm> (gdb) p *fsm $6 = {list = {next = 0x5555557a7680 <fsm_msc_mgcp>, prev = 0x5555557a85a0 <subscr_conn_fsm>}, instances = {next = 0x5555558c7590, prev = 0x5555558c7590}, name = 0x555555597422 "A-RESET", states = 0x5555557a9320 <fsm_states>, num_states = 2, allstate_event_mask = 0, allstate_action = 0x0, cleanup = 0x0, timer_cb = 0x555555586a70 <fsm_reset_ack_timeout_cb>, log_subsys = 6, event_names = 0x0, pre_term = 0x0} (gdb)
Updated by stsp about 6 years ago
Another segfault in osmo-msc, this time during 'show fsm-instances all'.
It's not immediately apparent to me if this is the same problem, though.
Program received signal SIGSEGV, Segmentation fault. __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:120 120 ../sysdeps/x86_64/multiarch/../strlen.S: No such file or directory. (gdb) up #1 0x00007ffff64a38c5 in _IO_vfprintf_internal (s=s@entry=0x7fffffffc8f0, format=<optimized out>, format@entry=0x7ffff7bcd58a " Child: '%s'%s", ap=ap@entry=0x7fffffffca88) at vfprintf.c:1643 1643 vfprintf.c: No such file or directory. (gdb) #2 0x00007ffff64ce440 in _IO_vsnprintf (string=0x7fffffffcaa0 " Child: 'l: 'DEBUG', State: 'SUBSCR_CONN_S_COMMUNICATING'\r\n", maxlen=<optimized out>, format=0x7ffff7bcd58a " Child: '%s'%s", args=0x7fffffffca88) at vsnprintf.c:114 114 vsnprintf.c: No such file or directory. (gdb) #3 0x00007ffff7bbf988 in vty_out (vty=0x55555589ae00, format=0x7ffff7bcd58a " Child: '%s'%s") at vty.c:268 268 len = vsnprintf(buf, sizeof buf, format, args); (gdb) #4 0x00007ffff7bc81fc in vty_out_fsm_inst (vty=0x55555589ae00, fsmi=0x5555558ca670) at fsm_vty.c:106 106 vty_out(vty, " Child: '%s'%s", child->name, VTY_NEWLINE); (gdb) p child $1 = (struct osmo_fsm_inst *) 0x5555558d0690 (gdb) p child->name $2 = 0x555502fee0e0 <error: Cannot access memory at address 0x555502fee0e0> (gdb) p *fsmi $3 = {list = {next = 0x5555558cad10, prev = 0x5555557a85b0 <subscr_conn_fsm+16>}, fsm = 0x5555557a85a0 <subscr_conn_fsm>, id = 0x5555558cd9c0 "1645857463", name = 0x5555558cf5b0 "Subscr_Conn(1645857463)[0x5555558ca670]", priv = 0x5555558d0430, log_level = 1, state = 3, T = 0, timer = {node = {rb_parent_color = 93824995881281, rb_right = 0x5555558ceaf0, rb_left = 0x0}, list = { next = 0x5555558ca6c8, prev = 0x5555558ca6c8}, timeout = {tv_sec = 1519644538, tv_usec = 89894}, active = 0, cb = 0x7ffff730dada <fsm_tmr_cb>, data = 0x5555558ca670}, proc = {parent = 0x0, parent_term_event = 0, children = {next = 0x5555558d0690, prev = 0x5555558d0690}, child = {next = 0x5555558ca720, prev = 0x5555558ca720}}} (gdb) p *child $4 = {list = {next = 0x5555558ca710, prev = 0x5555558ca710}, fsm = 0x5555558d0430, id = 0x71 <error: Cannot access memory at address 0x71>, name = 0x555502fee0e0 <error: Cannot access memory at address 0x555502fee0e0>, priv = 0x0, log_level = 0, state = 0, T = 1435299632, timer = {node = {rb_parent_color = 0, rb_right = 0x0, rb_left = 0x0}, list = {next = 0x7ffff6c6afe2, prev = 0x4}, timeout = {tv_sec = 0, tv_usec = 0}, active = 1, cb = 0x2000000, data = 0x71}, proc = {parent = 0x555502fee0e0, parent_term_event = 1435277472, children = { next = 0x0, prev = 0x5555557abdc0}, child = {next = 0x0, prev = 0x0}}}
Updated by stsp about 6 years ago
The above crash was found while investigating https://osmocom.org/issues/2779
It might be a side-effect of the bug discussed there.
Updated by laforge about 6 years ago
- Related to Bug #3007: make sure all libosmocore code can tolerate FSMs without event names added
Updated by dexter about 6 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 80
I have now upgraded the FSMs in question with event names:
https://gerrit.osmocom.org/6937 (mgcp_client_fsm)
https://gerrit.osmocom.org/6930 (a_reset)
https://gerrit.osmocom.org/6947 (fsm_msc_mgcp)
Updated by dexter about 6 years ago
- % Done changed from 80 to 100
I also added event names for the BSC now:
Updated by laforge about 6 years ago
- Status changed from In Progress to Resolved