From 7b75305e3c15da7a6b93e07390d42113b1516074 Mon Sep 17 00:00:00 2001
From: Melissa Elkadi <melissa@episci.com>
Date: Fri, 3 Jun 2022 17:11:36 -0700
Subject: [PATCH] pthread_create, RT scheduler, and address sanitizer are
incompatible in Ubuntu 18.04
When we run with the RT scheduler and the address sanitizer in Ubuntu
18.04, pthread_create will hang and never create threads. This adds
some explanatory text in CMakeLists.txt to explain about this issue.
---
cmake_targets/CMakeLists.txt | 16 ++++++++++++++++
openair2/LAYER2/NR_MAC_gNB/gNB_scheduler_RA.c | 4 ++--
openair2/NR_PHY_INTERFACE/NR_IF_Module.c | 2 +-
3 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/cmake_targets/CMakeLists.txt b/cmake_targets/CMakeLists.txt
index c08d9378b84..08809624ebe 100644
--- a/cmake_targets/CMakeLists.txt
+++ b/cmake_targets/CMakeLists.txt
@@ -247,6 +247,22 @@ add_boolean_option(SANITIZE_ADDRESS False "enable the address sanitizer (ASan)")
if (SANITIZE_ADDRESS)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fsanitize=address -fno-omit-frame-pointer -fno-common")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=address -fno-omit-frame-pointer -fno-common")
+ # There seems to be some incompatibility with pthread_create and the RT scheduler, which
+ # results in pthread_create hanging.
+ #
+ # When we switch from Ubuntu 16.04 to 18.04, we found that running with the address sanitizer,
+ # the pthread_create function calls were not working. The inital thought was that we were
+ # trying to create a thread that was not-blocking and would eventually crash the machine during
+ # the run. After more debugging, we found that we would never even start the thread. We narrowed
+ # down the first two instances of pthread_create in the gNB and NR UE to be sctp_eNB_task and
+ # one_thread, respectively. We found that adding sleeps, and various other pauses to the threads
+ # had not effect. From there, we found that if we add an abort(); prior to the thread loop, we
+ # do not execute that. This indicated to us that the problem is not likely to be a non-blocking
+ # thread, but perhaps and issue with pthread_create itself. From there we begain to research the
+ # issue on the web. See: https://github.com/google/sanitizers/issues/1125
+ #
+ # Google searching indicates this appears to be a problem since at least 2018. This could be something
+ # wrong in the pthread library, or something subtly wrong in this CMakeLists.txt. Use Ubuntu 20.04 instead.
endif ()
add_definitions("-DASN_DISABLE_OER_SUPPORT")
diff --git a/openair2/LAYER2/NR_MAC_gNB/gNB_scheduler_RA.c b/openair2/LAYER2/NR_MAC_gNB/gNB_scheduler_RA.c
index eb05ec5e835..615c7b046d9 100644
--- a/openair2/LAYER2/NR_MAC_gNB/gNB_scheduler_RA.c
+++ b/openair2/LAYER2/NR_MAC_gNB/gNB_scheduler_RA.c
@@ -1326,7 +1326,7 @@ void nr_generate_Msg2(module_id_t module_idP, int CC_id, frame_t frameP, sub_fra
dl_req->nPDUs+=1;
nfapi_nr_dl_tti_pdsch_pdu_rel15_t *pdsch_pdu_rel15 = &dl_tti_pdsch_pdu->pdsch_pdu.pdsch_pdu_rel15;
- LOG_D(NR_MAC,"[gNB %d][RAPROC] CC_id %d Frame %d, slotP %d: Generating RA-Msg2 DCI, rnti 0x%x, state %d, CoreSetType %d\n",
+ LOG_A(NR_MAC,"[gNB %d][RAPROC] CC_id %d Frame %d, slotP %d: Generating RA-Msg2 DCI, rnti 0x%x, state %d, CoreSetType %d\n",
module_idP, CC_id, frameP, slotP, ra->RA_rnti, ra->state,pdcch_pdu_rel15->CoreSetType);
// SCF222: PDU index incremented for each PDSCH PDU sent in TX control message. This is used to associate control
@@ -1787,7 +1787,7 @@ void nr_generate_Msg4(module_id_t module_idP, int CC_id, frame_t frameP, sub_fra
dl_req->nPDUs+=1;
nfapi_nr_dl_tti_pdsch_pdu_rel15_t *pdsch_pdu_rel15 = &dl_tti_pdsch_pdu->pdsch_pdu.pdsch_pdu_rel15;
- LOG_D(NR_MAC, "[gNB %d] [RAPROC] CC_id %d Frame %d, slotP %d: Generating RA-Msg4 DCI, state %d\n", module_idP, CC_id, frameP, slotP, ra->state);
+ LOG_A(NR_MAC, "[gNB %d] [RAPROC] CC_id %d Frame %d, slotP %d: Generating RA-Msg4 DCI, state %d\n", module_idP, CC_id, frameP, slotP, ra->state);
// SCF222: PDU index incremented for each PDSCH PDU sent in TX control message. This is used to associate control
// information to data and is reset every slot.
diff --git a/openair2/NR_PHY_INTERFACE/NR_IF_Module.c b/openair2/NR_PHY_INTERFACE/NR_IF_Module.c
index 8d4de8823bc..ac0e48a9107 100644
--- a/openair2/NR_PHY_INTERFACE/NR_IF_Module.c
+++ b/openair2/NR_PHY_INTERFACE/NR_IF_Module.c
@@ -77,7 +77,7 @@ void handle_nr_rach(NR_UL_IND_t *UL_info)
bool in_timewindow = frame_diff == 0 || (frame_diff == 1 && UL_info->slot < 7);
if (UL_info->rach_ind.number_of_pdus > 0 && in_timewindow) {
- LOG_D(MAC,"UL_info[Frame %d, Slot %d] Calling initiate_ra_proc RACH:SFN/SLOT:%d/%d\n",
+ LOG_A(MAC,"UL_info[Frame %d, Slot %d] Calling initiate_ra_proc RACH:SFN/SLOT:%d/%d\n",
UL_info->frame, UL_info->slot, UL_info->rach_ind.sfn, UL_info->rach_ind.slot);
for (int i = 0; i < UL_info->rach_ind.number_of_pdus; i++) {
UL_info->rach_ind.number_of_pdus--;
--
GitLab