Project

General

Profile

Actions

Bug #2924

closed

osmo-msc MGCP FSM has no event names

Added by laforge about 6 years ago. Updated about 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
02/10/2018
Due date:
% Done:

100%

Resolution:
Spec Reference:

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

Related to libosmocore - Bug #3007: make sure all libosmocore code can tolerate FSMs without event namesResolvedstsp02/26/2018

Actions
Actions #1

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) 
Actions #2

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}}}
Actions #3

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.

Actions #4

Updated by laforge about 6 years ago

  • Related to Bug #3007: make sure all libosmocore code can tolerate FSMs without event names added
Actions #5

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)

Actions #6

Updated by dexter about 6 years ago

  • % Done changed from 80 to 100

I also added event names for the BSC now:

https://gerrit.osmocom.org/6952

Actions #7

Updated by laforge about 6 years ago

  • Status changed from In Progress to Resolved
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)