Dear Ivan, all,
I started to do work on the PCU and didn't compile C++ for a long time.
I was surprised how long it takes to compile the code. From my point
of view we are taking the hit of g++ without really using any of the
features that C++ vould provide (e.g. no stack variables with automatic
cleanup..).
osmo_timer_del is an idempotent operation. There is no requirement
to check if it is running. If you don't want a timer to run, delete
it. Maybe one should have called the method _unschedule, _cancel to
make this more clear.
---
src/gprs_bssgp_pcu.cpp | 6 ++----
src/sysmo_sock.cpp | 3 +--
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/src/gprs_bssgp_pcu.cpp b/src/gprs_bssgp_pcu.cpp
index 54753b8..c791913 100644
--- a/src/gprs_bssgp_pcu.cpp
+++ b/src/gprs_bssgp_pcu.cpp
@@ -515,8 +515,7 @@ static int nsvc_signal_cb(unsigned int subsys, unsigned int signal,
case S_NS_BLOCK:
if (nsvc_unblocked) {
nsvc_unblocked = 0;
- if (osmo_timer_pending(&bvc_timer))
- osmo_timer_del(&bvc_timer);
+ osmo_timer_del(&bvc_timer);
bvc_sig_reset = 0;
bvc_reset = 0;
bvc_unblocked = 0;
@@ -646,8 +645,7 @@ void gprs_bssgp_destroy(void)
if (!bssgp_nsi)
return;
- if (osmo_timer_pending(&bvc_timer))
- osmo_timer_del(&bvc_timer);
+ osmo_timer_del(&bvc_timer);
osmo_signal_unregister_handler(SS_L_NS, nsvc_signal_cb, NULL);
diff --git a/src/sysmo_sock.cpp b/src/sysmo_sock.cpp
index a4cc6de..d4fb5a6 100644
--- a/src/sysmo_sock.cpp
+++ b/src/sysmo_sock.cpp
@@ -304,8 +304,7 @@ void pcu_l1if_close(void)
if (!state)
return;
- if (osmo_timer_pending(&state->timer))
- osmo_timer_del(&state->timer);
+ osmo_timer_del(&state->timer);
bfd = &state->conn_bfd;
if (bfd->fd > 0)
--
1.8.3.2
Dear Andreas, Ivan,
when trying to understand the CPU usage of the PCU without having
any subscribers I noticed the following backtrace:
#0 _int_malloc (av=0x402fe4d4, bytes=52) at malloc.c:3241
#1 0x4023a3b8 in __GI___libc_malloc (bytes=52) at malloc.c:2859
#2 0x4929b6e8 in _talloc_zero () from /usr/lib/libosmocore.so.4
#3 0x49422e44 in vector_init () from /usr/lib/libosmovty.so.0
#4 0x4941f1f8 in install_element () from /usr/lib/libosmovty.so.0
#5 0x492e602c in gprs_ns_vty_init () from /usr/lib/libosmogb.so.2
#6 0x0001b670 in gprs_bssgp_create (local_port=<optimized out>, sgsn_ip=184194049,
sgsn_port=<optimized out>, nsei=<optimized out>, nsvci=2, bvci=2, mcc=<optimized out>,
mnc=<optimized out>, lac=1, rac=0, cell_id=0) at gprs_bssgp_pcu.cpp:585
#7 0x00016990 in pcu_rx_info_ind (info_ind=0x7) at pcu_l1_if.cpp:431
#8 pcu_rx (msg_type=<optimized out>, pcu_prim=0x3) at pcu_l1_if.cpp:577
#9 0x00017914 in pcu_sock_read (bfd=0x6a3f0) at sysmo_sock.cpp:151
#10 pcu_sock_cb (bfd=0x6a3f0, flags=1) at sysmo_sock.cpp:218
#11 0x49294ff4 in osmo_select_main () from /usr/lib/libosmocore.so.4
#12 0x0000a668 in main (argc=<optimized out>, argv=0xbee40b04) at pcu_main.cpp:219
This means when a info indication is received gprs_bssgp_create will
be called which will re-initialize the VTY commands but more important
re-set vty_nsi inside the VTY code of libosmogb. But it also means that
vty_nsi will be a dangling pointer in case of
1.) gprs_ns_nsip_connect, btsctx_alloc, gprs_ns_nsip_listen fail
2.) Between the sysmobts software exiting and re-starting and bringing
OML back up
3.) More cases that I might not understand.
The dangling pointer will lead to a crash when the VTY of the PCU is
used in such situation/window.
does any of you care to fix that race? I think the easiest would be
to just close/open/bind/listen/connect on the NS once we get a new
config.
holger
--
- Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte