- **status**: accepted --> review
---
** [tickets:#1817] imm: IMMND crashes when receiving ccb-apply request for
purged ccb**
**Status:** review
**Milestone:** 4.7.2
**Created:** Tue May 10, 2016 03:20 AM UTC by Hung Nguyen
**Last Updated:** Thu May 12, 2016 04:20 AM UTC
**Owner:** Hung Nguyen
**Attachments:**
-
[logs_n_testapp.tgz](https://sourceforge.net/p/opensaf/tickets/1817/attachment/logs_n_testapp.tgz)
(26.1 MB; application/x-compressed)
The application tried to delete an config object.
While waiting for response from OI for the delete operation, timeout occurred.
It seemed that the IMMA_SYNCR_TIMEOUT is smaller than IMMA_OI_CALLBACK_TIMEOUT.
CcbObjectDelete() returned ERR_TIMEOUT and the library sent A2ND_CL_TIMEOUT to
server.
~~~
library trace
14:12:13.100461 imma [24022:imma_om_api.c:2682] >> ccb_object_delete_common
14:12:23.109589 imma [24022:imma_om_api.c:2901] TR objectDelete send RETURNED:5
14:12:23.109622 imma [24022:imma_om_api.c:2995] TR objectDelete really
RETURNING:5
14:12:23.109632 imma [24022:imma_om_api.c:2996] << ccb_object_delete_common
server trace
14:12:23.109681 osafimmnd [5140:immsv_evt.c:5457] T8 Received:
IMMND_EVT_A2ND_CL_TIMEOUT (93) from 2010f
14:12:23.109708 osafimmnd [5140:immnd_evt.c:2019] >>
immnd_evt_proc_cl_imma_timeout
14:12:23.109721 osafimmnd [5140:immnd_evt.c:2021] T2 timeout in imma library
for handle: 46200002010f
14:12:23.109728 osafimmnd [5140:ImmModel.cc:12697] >> purgeSyncRequest
14:12:23.109736 osafimmnd [5140:ImmModel.cc:12801] T5 Purged Ccb continuation
for ccb:354 in state 5
14:12:23.109742 osafimmnd [5140:ImmModel.cc:12804] << purgeSyncRequest
14:12:23.109779 osafimmnd [5140:immnd_evt.c:2049] <<
immnd_evt_proc_cl_imma_timeout
~~~
Later the timeout occurred in IMM server (::cleanTheBasement).
~~~
14:12:23.387649 osafimmnd [5140:ImmModel.cc:12874] TR Checking active ccb 354
for deadlock or blocked implementer
14:12:23.387655 osafimmnd [5140:ImmModel.cc:12876] TR state:5
waitsart:1462363933 PberestartId:0
14:12:23.387660 osafimmnd [5140:ImmModel.cc:12905] T5 CCB 354 timeout while
waiting on implementer reply
...
14:12:23.389093 osafimmnd [5140:immnd_proc.c:1244] WA Timeout while waiting for
implementer, aborting ccb:354
14:12:23.389116 osafimmnd [5140:immsv_evt.c:5438] T8 Sending:
IMMD_EVT_ND2D_ABORT_CCB to 0
...
14:12:23.394866 osafimmnd [5140:immsv_evt.c:5457] T8 Received:
IMMND_EVT_D2ND_ABORT_CCB (62) from 0
14:12:23.394871 osafimmnd [5140:immnd_evt.c:7488] >> immnd_evt_proc_ccb_finalize
14:12:23.394876 osafimmnd [5140:immnd_evt.c:6730] >> immnd_evt_ccb_abort
14:12:23.394880 osafimmnd [5140:immnd_evt.c:6734] TR We expect there to be a PBE
14:12:23.394949 osafimmnd [5140:ImmModel.cc:5792] >> ccbAbort
14:12:23.394973 osafimmnd [5140:ImmModel.cc:5801] T5 ABORT CCB 354
14:12:23.394987 osafimmnd [5140:ImmModel.cc:5822] NO Aborting ccb 354 while
waiting for replies from implementers on DELETE-OP
14:12:23.394997 osafimmnd [5140:ImmModel.cc:5870] NO Ccb 354 ABORTED
(immcfg_SC-2-1_24022)
14:12:23.395008 osafimmnd [5140:immnd_evt.c:6752] T2 ccb:354 is originated from
this node
14:12:23.395036 osafimmnd [5140:immnd_evt.c:6862] << immnd_evt_ccb_abort
14:12:23.395043 osafimmnd [5140:immnd_evt.c:7506] T2 ccbFinalize originated at
this node => Send reply
14:12:23.395047 osafimmnd [5140:immnd_evt.c:7513] T2 client ==
m_IMMSV_UNPACK_HANDLE_HIGH(clnt_hdl))??: 0 == 0
14:12:23.395064 osafimmnd [5140:immnd_evt.c:7517] WA IMMND - Client went down
so no response
14:12:23.395069 osafimmnd [5140:ImmModel.cc:5951] >> ccbTerminate
14:12:23.395073 osafimmnd [5140:ImmModel.cc:5960] T5 terminate the CCB 354
14:12:23.395078 osafimmnd [5140:ImmModel.cc:6019] T2 Aborting Delete of
safAmfNodeGroup=scale_in_shutdown,safAmfCluster=myAmfCluster
14:12:23.395084 osafimmnd [5140:ImmModel.cc:6025] T5 Flags after remove delete
lock:0
14:12:23.395089 osafimmnd [5140:ImmModel.cc:6148] T5 Ccb Wait-time for GC set.
State: 12/ABORTED
14:12:23.395095 osafimmnd [5140:ImmModel.cc:6178] << ccbTerminate
14:12:23.395099 osafimmnd [5140:immnd_evt.c:7535] << immnd_evt_proc_ccb_finalize
~~~
The application then invoked CcbApply() and IMMND crashed.
~~~
14:12:26.113187 osafimmnd [5140:immsv_evt.c:5457] T8 Received:
IMMND_EVT_A2ND_CCB_APPLY (33) from 0
14:12:26.113195 osafimmnd [5140:immnd_evt.c:7578] >> immnd_evt_proc_ccb_apply
14:12:26.113204 osafimmnd [5140:immnd_evt.c:7599] TR We expect there to be a PBE
14:12:26.113211 osafimmnd [5140:ImmModel.cc:5176] >> ccbApply
14:12:26.113217 osafimmnd [5140:ImmModel.cc:5180] T5 APPLYING CCB ID:354
14:12:26 SC-2-1 osafimmnd[5140]: ImmModel.cc:5242: ccbApply: Assertion
'reqConn==0 || (ccb->mOriginatingConn == reqConn)' failed.
~~~
---
testapp to reproduce the problem
root@SC-1:~# immcfg -f ./test_class.xml
root@SC-1:~# ./test_oi &
[1] 1256
root@SC-1:~# export IMMA_SYNCR_TIMEOUT=300
root@SC-1:~# ./test_ccb
saImmOmCcbObjectCreate_2 5
---
Sent from sourceforge.net because [email protected] is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
