Patch Set 1: > Do you conceptually understand when this can happen? If yes, > please add the rationale to the commit log message
I'm not entirely sure as it's difficult to say only from the bt crash and I don't have deep knowledge about the protocol, but my bet is that it can happen if: 1- gsm0808_assign_req() calls handle_new_assignment() which sends an CHAN ACTIVATE msg and arms T10 timer. 2- ACTIVATE ACK is received (handle_chan_ack), which calls gsm48_send_rr_ass_cmd() which sends an ASSIGNMENT CMD, and doesn't disable/modify T10 timer. 3- T10 timeout is triggered (assignment_t10_timeout()), which sets conn->secondary_lchan = NULL 4- Immediately after, the ASSIGNMENT FAILURE message (which might have been already queued) is processed in handle_ass_fail, and then the crash occurs. This race condition is not an issue for handle_ass_compl() path because there's this check there which would trigger most probably if secondary_lchan is NULL: "if (conn->secondary_lchan != msg->lchan)" If it makes sense for you too then I can add this description to the commit and submit it. -- To view, visit https://gerrit.osmocom.org/4277 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ied5bd90b9c06f27135a2e3c46e40d49d27d9a387 Gerrit-PatchSet: 1 Gerrit-Project: openbsc Gerrit-Branch: master Gerrit-Owner: Pau Espin Pedrol <[email protected]> Gerrit-Reviewer: Harald Welte <[email protected]> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Pau Espin Pedrol <[email protected]> Gerrit-HasComments: No
