Bug #5551
closedbssmap_reset.c:249:2: runtime error: member access within null pointer of type 'struct bssmap_reset'
100%
Description
bssmap_reset.c:249:2: runtime error: member access within null pointer of type 'struct bssmap_reset'
Program received signal SIGSEGV, Segmentation fault.
0x0000555556413e5f in bssmap_reset_resend_reset ()
(gdb) bt
#0 0x0000555556413e5f in bssmap_reset_resend_reset ()
#1 0x000055555608a77b in msc_bssmap_reset ()
#2 0x00007ffff7246c08 in cmd_execute_command_real (vline=0x60b0009a6f50, vty=0x614000002aa0, cmd=0x0)
at command.c:2604
#3 0x00007ffff7247369 in cmd_execute_command (vline=0x60b0009a6f50, vty=0x614000002aa0, cmd=0x0,
vtysh=0) at command.c:2656
#4 0x00007ffff7257f60 in vty_command (vty=0x614000002aa0) at vty.c:464
#5 0x00007ffff725b999 in vty_execute (vty=0x614000002aa0) at vty.c:729
#6 0x00007ffff72654b7 in vty_read (vty=0x614000002aa0) at vty.c:1471
#7 0x00007ffff7270e58 in client_data (fd=0x610000004ab8, what=1) at telnet_interface.c:150
#8 0x00007ffff68008a7 in poll_disp_fds (n_fd=87) at select.c:361
#9 0x00007ffff6800a34 in _osmo_select_main (polling=0) at select.c:399
#10 0x00007ffff6800b17 in osmo_select_main_ctx (polling=0) at select.c:455
#11 0x0000555555ea33a6 in main ()
this happens when the vty command msc 0 bssmap reset is issued
Updated by laforge almost 2 years ago
apparently this happens if we have no msc 0 section in the config file
Updated by msuraev over 1 year ago
- Status changed from New to In Progress
- % Done changed from 0 to 10
Updated by msuraev over 1 year ago
- % Done changed from 10 to 50
I'm unable to reproduce this (with and without 'msc 0' entry in config) but https://gerrit.osmocom.org/c/osmo-bsc/+/28892 should fix the crash nevertheless.
Updated by neels over 1 year ago
looking at the code, I see no way how a bssmap_reset == NULL pointer can occur.
For all existing 'msc' instances, the bssmap_reset FSM instance is allocated at program startup in osmo_bsc_sigtran_init().
osmo_bsc_sigtran_init() returns success only after bssmap_reset FSM allocation occured.
The allocation is guarded by OSMO_ASSERT(), so it always returns non-NULL.
Those FSM instances never terminate, and have no cleanup() cb.
There is no code that sets bssmap_reset = NULL anywhere.
I don't see any reason besides stack corruption for this SEGV to happen.
This came to my attention because the submitted patch fixes an unexistent issue...
Updated by over 1 year ago
- Status changed from In Progress to Resolved
- % Done changed from 50 to 100
Applied in changeset osmo-bsc|56dc61e3f587bcf927793ac5700e0e1a53edb815.
