Project

General

Profile

Bug #5222

SIGSEGV on call establishment

Added by keith about 2 months ago. Updated about 2 months ago.

Status:
Resolved
Priority:
High
Assignee:
Target version:
-
Start date:
08/30/2021
Due date:
% Done:

100%

Spec Reference:

Description

segfault in pdch_ulc_get_node()

ulc is NULL:

Program received signal SIGSEGV, Segmentation fault.
pdch_ulc_get_node (ulc=0x0, fn=fn@entry=55453) at /usr/src/debug/osmo-pcu/0.9.0+gitAUTOINC+c4fe1f97b4-r0.18/git/src/pdch_ul_controller.c:78

Currently looking at an optimised binary running on the sysmoBTS;

Up the stack in handle_ph_data_ind() osmo-bts-sysmo/sysmo_l1_if.c:196

(gdb) p bts->trx[0].pdch[0]->ulc
$41 = (struct pdch_ulc *) 0x0
(gdb) p bts->trx[0].pdch[1]->ulc
$42 = (struct pdch_ulc *) 0x0
(gdb) p bts->trx[0].pdch[2]->ulc
$43 = (struct pdch_ulc *) 0x0
(gdb) p bts->trx[0].pdch[3]->ulc
$44 = (struct pdch_ulc *) 0x0
(gdb) p bts->trx[0].pdch[4]->ulc
$45 = (struct pdch_ulc *) 0x0
(gdb) p bts->trx[0].pdch[5]->ulc
$46 = (struct pdch_ulc *) 0x140a40
(gdb) p bts->trx[0].pdch[6]->ulc
$47 = (struct pdch_ulc *) 0x1418f0
(gdb) p bts->trx[0].pdch[7]->ulc
$48 = (struct pdch_ulc *) 0x1427a0

osmo-bsc Timeslot Config:

   timeslot 0
    phys_chan_config CCCH
    hopping enabled 0
   timeslot 1
    phys_chan_config SDCCH8
    hopping enabled 0
   timeslot 2
    phys_chan_config TCH/H
    hopping enabled 0
   timeslot 3
    phys_chan_config TCH/H
    hopping enabled 0
   timeslot 4
    phys_chan_config TCH/F_TCH/H_PDCH
    hopping enabled 0
   timeslot 5
    phys_chan_config TCH/F_TCH/H_PDCH
    hopping enabled 0
   timeslot 6
    phys_chan_config TCH/F_TCH/H_PDCH
    hopping enabled 0
   timeslot 7
    phys_chan_config PDCH
    hopping enabled 0

I changed timeslot 4 to a TCH/H and then the crash happens again in the same place, only now, ulc for timeslot 5 is NULL!


(gdb) p bts->trx[0].pdch[5]->ulc
$63 = (struct pdch_ulc *) 0x0
(gdb) p bts->trx[0].pdch[6]->ulc
$64 = (struct pdch_ulc *) 0x140a40

to be clear:

#2  0x0001589c in handle_ph_data_ind (fl1h=0x13f430, fl1h=0x13f430, l1p_msg=0x13f620, data_ind=0x13f6e8)
    at /usr/src/debug/osmo-pcu/0.9.0+gitAUTOINC+c4fe1f97b4-r0.18/git/src/osmo-bts-sysmo/sysmo_l1_if.c:196
196    in /usr/src/debug/osmo-pcu/0.9.0+gitAUTOINC+c4fe1f97b4-r0.18/git/src/osmo-bts-sysmo/sysmo_l1_if.c
(gdb) p data_ind->u8Tn
$68 = 5 '\005'

Associated revisions

Revision 3bbb3cc1 (diff)
Added by pespin about 2 months ago

Fix crash with dyn TS when using direct pcu

It seems there may be a race conditon where lower layers (direct PCU)
send UL blocks to us while the PDCH was already disabled (due to a call
entering on a dynamic TS).
As the PDCH is disabled, the ULC is NULL and shouldn't be used before
being enabled again.

Related: OS#5222
Change-Id: I4b8931f0cc7cfc787a1cc35196295402524b15c3

Revision 25d60caf (diff)
Added by pespin about 2 months ago

sched: Lower log level of RTS on disabled pdch

These messages are expected under some circumstances, such as when
direct phy is used and a chan is disabled (eg. dyn TS). This happens
because PCU asks for chan de-activation through PCUIF while at the same
time marking the PDCH locally as disabled. Hence, in the time the BTS
manages to disable it on the lower layers, the phy still sends us
RTS indications.

Let's keep it under NOTICE to avoid clogging the logs in production
setups which are usually using global level of NOTICE or ERROR.

Related: OS#5222
Change-Id: Iab9e1590b504bf05dc693e27550b30db0dffcbc7

History

#1 Updated by laforge about 2 months ago

  • Assignee set to pespin
  • Priority changed from Normal to High

#2 Updated by pespin about 2 months ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 90

Should be fixed by:
https://gerrit.osmocom.org/c/osmo-pcu/+/25289 Fix crash with dyn TS when using direct pcu

#3 Updated by pespin about 2 months ago

  • Assignee changed from pespin to keith

Assigning back to keith for him to test once the patch is merged and confirm the issue is solved.

#4 Updated by keith about 2 months ago

Thanks. Seeing as how it is merged, I'll wait for the nightly build and feed back tomorrow.

#5 Updated by keith about 2 months ago

  • Status changed from Feedback to Resolved
  • % Done changed from 90 to 100

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)