Commit 7b75305e authored by Melissa Elkadi's avatar Melissa Elkadi Committed by Robert Schmidt

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.
parent d7dae8fa
...@@ -247,6 +247,22 @@ add_boolean_option(SANITIZE_ADDRESS False "enable the address sanitizer (ASan)") ...@@ -247,6 +247,22 @@ add_boolean_option(SANITIZE_ADDRESS False "enable the address sanitizer (ASan)")
if (SANITIZE_ADDRESS) if (SANITIZE_ADDRESS)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fsanitize=address -fno-omit-frame-pointer -fno-common") 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") 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 () endif ()
add_definitions("-DASN_DISABLE_OER_SUPPORT") add_definitions("-DASN_DISABLE_OER_SUPPORT")
......
...@@ -1326,7 +1326,7 @@ void nr_generate_Msg2(module_id_t module_idP, int CC_id, frame_t frameP, sub_fra ...@@ -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; dl_req->nPDUs+=1;
nfapi_nr_dl_tti_pdsch_pdu_rel15_t *pdsch_pdu_rel15 = &dl_tti_pdsch_pdu->pdsch_pdu.pdsch_pdu_rel15; 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); 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 // 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 ...@@ -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; dl_req->nPDUs+=1;
nfapi_nr_dl_tti_pdsch_pdu_rel15_t *pdsch_pdu_rel15 = &dl_tti_pdsch_pdu->pdsch_pdu.pdsch_pdu_rel15; 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 // 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. // information to data and is reset every slot.
......
...@@ -77,7 +77,7 @@ void handle_nr_rach(NR_UL_IND_t *UL_info) ...@@ -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); bool in_timewindow = frame_diff == 0 || (frame_diff == 1 && UL_info->slot < 7);
if (UL_info->rach_ind.number_of_pdus > 0 && in_timewindow) { 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); 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++) { for (int i = 0; i < UL_info->rach_ind.number_of_pdus; i++) {
UL_info->rach_ind.number_of_pdus--; UL_info->rach_ind.number_of_pdus--;
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment