Project

General

Profile

Bug #5226

ulc NULL in pdch_ulc_release_tbf()

Added by keith 17 days ago. Updated 13 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Target version:
-
Start date:
09/02/2021
Due date:
% Done:

0%

Spec Reference:

Description

(gdb) bt
#0  0xb6ebe3f8 in rb_first () from /usr/lib/libosmocore.so.17
#1  0x0003c394 in pdch_ulc_release_tbf (ulc=0x0, tbf=tbf@entry=0x187208) at /usr/src/debug/osmo-pcu/0.9.0+gitAUTOINC+bf7bde1cbb-r0.18/git/src/pdch_ul_controller.c:273
#2  0x00038eec in gprs_rlcmac_pdch::detach_tbf (this=0x137a34, tbf=tbf@entry=0x187208) at /usr/src/debug/osmo-pcu/0.9.0+gitAUTOINC+bf7bde1cbb-r0.18/git/src/pdch.cpp:1074
#3  0x0002b1c4 in tbf_unlink_pdch (tbf=0x187208) at /usr/src/debug/osmo-pcu/0.9.0+gitAUTOINC+bf7bde1cbb-r0.18/git/src/tbf.cpp:247
#4  tbf_free (tbf=0x187208) at /usr/src/debug/osmo-pcu/0.9.0+gitAUTOINC+bf7bde1cbb-r0.18/git/src/tbf.cpp:280
#5  0x0002c130 in tbf_fsm_timer_cb (fi=<optimized out>) at /usr/src/debug/osmo-pcu/0.9.0+gitAUTOINC+bf7bde1cbb-r0.18/git/src/tbf_fsm.c:368
#6  0xb6eb4090 in ?? () from /usr/lib/libosmocore.so.17

Associated revisions

Revision 1d663d92 (diff)
Added by pespin 16 days ago

pdch: Make sure pending ImmAssRej scheduled for disabled pdch are dropped

When a PDCH TS becomes disabled (eg due to dyn TS being used for a
call), we are currently freeing all attached PDCHs in order to avoid
further use of it. However, pdch_free_all_tbf() was only freeing TBFs
attached to the PDCH, that is, TBFs having a valid TFI assigned.
There are some cases where temporary dummy TBFs are created which have
no TFI assigned, such as when creating an ImmAssReject. Let's take those
into account too, and make sure they are freed.

Related: OS#5226
Change-Id: Ibfe78448ebdedc8b049c80664711e166d910f9b7

History

#1 Updated by keith 17 days ago

I was unable to reproduce it running osmo-pcu on x86 with l1fwd-proxy, but can provoke the crash pretty easy by causing some TBFs then calling the MS, so I assume it is a close relation of #5222. cousins, perhaps?

EDIT: ...can provoke the crash on sysmoBTS hardware with direct phy access

EDIT: How I provoked the crash:

1. Open an app on an MS, browser or whatever, and open a page that will genertate some IP traffic, or check email, mastodon etc.. "causing" TBFs to be created..
2. Call this phone.
3. Boom!

#2 Updated by pespin 16 days ago

Hi keith,
Can you explain a bit better the scenario? I don't really get what you mean with "causing some TBFs then calling the MS"a, sorry.
can you provide some logs (or PCU gsmtap+gsmtap_log even better) around the time this happens?

#3 Updated by pespin 16 days ago

  • Status changed from New to Feedback

I submitted this fix, but I'm not really sure if it's going to solve the crash you are experience since I lack detailed information.

https://gerrit.osmocom.org/c/osmo-pcu/+/25330 pdch: Make sure pending ImmAssRej scheduled for disabled pdch are dropped

#4 Updated by keith 13 days ago

  • Status changed from Feedback to In Progress

Just a quick note, very quickly testing this patch and still observing a crash, when using data and making calls.

I'll need to get back to it after some other tasks.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)