Attention is currently required from: lynxis lazus.
neels has posted comments on this change by lynxis lazus. ( https://gerrit.osmocom.org/c/osmo-msc/+/38491?usp=email )
Change subject: vlr_lu_fsm: terminate the FSM instead of dispatching only a signal to the parent ......................................................................
Patch Set 11: Code-Review+1
(1 comment)
File tests/msc_vlr/msc_vlr_test_authen_reuse.err:
https://gerrit.osmocom.org/c/osmo-msc/+/38491/comment/fed842f8_7e5c0267?usp=... : PS11, Line 184: DVLR vlr_lu_fsm(IMSI-901700000010650:MSISDN-42342:TMSI-0x03020100:GERAN-A:LU){VLR_ULA_S_DONE}: Deferring: will deallocate with msc_a(IMSI-901700000010650:MSISDN-42342:TMSI-0x03020100:GERAN-A:LU) I see here that we deallocate the msc_a much much earlier.
I am not sure about the details anymore, but there was a lot of trouble with instances deallocating, but dependent objects still accessing them for cleanup -- or dependent objects being talloc children and already disappearing before they can cleanup. Such tedious crap...
This "Deferring" is a sign that there was such trouble and the fix was to deallocate the msc_a later.
Now, there has been a general fix in osmocom for such problems, which is that we don't deallocate, but move to OTC_SELECT. It is quite possible that this patch finally gets rid of the old deferring that was necessary before we had OTC_SELECT?
I am writing this comment because, I expect that it's fine, but can you somehow check if it really is fine, please? If we use OTC_SELECT where it says "Deallocated" above on line 166 then we are fine...