subject:"\[tickets\] \[opensaf\:tickets\] #2647 ntfd\: ntfimcnd crashed on handling for Object creation callback"

[tickets] [opensaf:tickets] #2647 ntfd: ntfimcnd crashed on handling for Object creation callback

2017-11-13 Thread Srinivas Siva Mangipudy via Opensaf-tickets

commit 310ac5cdf625681c692ab2621d08c42dab80be0e
Author: vijayroy 
Date:   Tue Nov 14 12:07:54 2017 +0530

ntfd: fix to avoid ntfimcnd from dumping core dump during massive 
add/delete ops [#2647]



---

** [tickets:#2647] ntfd: ntfimcnd crashed on handling for Object creation 
callback**

**Status:** fixed
**Milestone:** 5.18.01
**Created:** Thu Oct 19, 2017 12:45 PM UTC by Srinivas Siva Mangipudy
**Last Updated:** Tue Nov 14, 2017 06:57 AM UTC
**Owner:** Srinivas Siva Mangipudy


1. Problem 
= = 
NTFimcnd crashed while 200k objects was created and the deleted in IMM, the 
classes  associated with these objects were also removed.
 
2. Analysis 
= =
A huge number of objects, about 200k objects, were created in IMM with PBE 
disabled. Then these objects were deleted in one CCB (by deleting the root 
object). After deleting the objects, the classes were also removed. Then the 
crash happened.

 
../../../../../../../opensaf/osaf/services/saf/ntfsv/ntfimcnd/ntfimcn_imm.c:167:
 get_rdn_attr_name:  Assertion '0' failed. 

When NTFimcnd created notifications, some information had to be looked up in 
IMM.  
NTFimcnd only asked for class information in case of object creation: 

static SaAisErrorT saImmOiCcbObjectCreateCallback(SaImmOiHandleT immOiHandle,   
 SaImmOiCcbIdT ccbId,   
 const SaImmClassNameT className,   
 const SaNameT *parentName, const 
SaImmAttrValuesT_2 **attr) { … dn_ptr = get_created_dn(className, parentName, 
attr); … } static void saImmOiCcbApplyCallback(SaImmOiHandleT immOiHandle, 
SaImmOiCcbIdT ccbId) { …
 switch (ccbUtilOperationData->operationType) { case 
CCBUTIL_CREATE: rdn_attr_name = get_rdn_attr_name(  
   ccbUtilOperationData- 
>param.create.className); 
internal_rc = ntfimcn_send_object_create_notification(  
   ccbUtilOperationData, rdn_attr_name, 
ccbLast); … }

In this case, NTF was still handling notifications for a big number of created 
objects.  Usually,  NTFimcnd cached the class information.  But because these 
objects belong to many classes, it had to ask IMM for class information. But  
the class was already removed in IMM.  IMM was much faster to create and delete 
the objects and class (with PBE disabled), while NTF  was still processing the 
objects, so the information was not there in IMM anymore, and the  crashed 
happened.


3. Reproduction 
= = 
Can be reproduced like below: - Disable PBE 1. Create a huge amount of objects 
with one parent object.  2. In my case, I created 2 root objects of two 
different classes with about 100k  child objects each Delete first root object, 
then delete the class associated with this object. 3. Delete second root 
object, delete the class associated with this object. 


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net 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.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2647 ntfd: ntfimcnd crashed on handling for Object creation callback

2017-11-13 Thread Srinivas Siva Mangipudy via Opensaf-tickets

- **status**: assigned --> fixed



---

** [tickets:#2647] ntfd: ntfimcnd crashed on handling for Object creation 
callback**

**Status:** fixed
**Milestone:** 5.18.01
**Created:** Thu Oct 19, 2017 12:45 PM UTC by Srinivas Siva Mangipudy
**Last Updated:** Mon Nov 06, 2017 09:07 AM UTC
**Owner:** Srinivas Siva Mangipudy


1. Problem 
= = 
NTFimcnd crashed while 200k objects was created and the deleted in IMM, the 
classes  associated with these objects were also removed.
 
2. Analysis 
= =
A huge number of objects, about 200k objects, were created in IMM with PBE 
disabled. Then these objects were deleted in one CCB (by deleting the root 
object). After deleting the objects, the classes were also removed. Then the 
crash happened.

 
../../../../../../../opensaf/osaf/services/saf/ntfsv/ntfimcnd/ntfimcn_imm.c:167:
 get_rdn_attr_name:  Assertion '0' failed. 

When NTFimcnd created notifications, some information had to be looked up in 
IMM.  
NTFimcnd only asked for class information in case of object creation: 

static SaAisErrorT saImmOiCcbObjectCreateCallback(SaImmOiHandleT immOiHandle,   
 SaImmOiCcbIdT ccbId,   
 const SaImmClassNameT className,   
 const SaNameT *parentName, const 
SaImmAttrValuesT_2 **attr) { … dn_ptr = get_created_dn(className, parentName, 
attr); … } static void saImmOiCcbApplyCallback(SaImmOiHandleT immOiHandle, 
SaImmOiCcbIdT ccbId) { …
 switch (ccbUtilOperationData->operationType) { case 
CCBUTIL_CREATE: rdn_attr_name = get_rdn_attr_name(  
   ccbUtilOperationData- 
>param.create.className); 
internal_rc = ntfimcn_send_object_create_notification(  
   ccbUtilOperationData, rdn_attr_name, 
ccbLast); … }

In this case, NTF was still handling notifications for a big number of created 
objects.  Usually,  NTFimcnd cached the class information.  But because these 
objects belong to many classes, it had to ask IMM for class information. But  
the class was already removed in IMM.  IMM was much faster to create and delete 
the objects and class (with PBE disabled), while NTF  was still processing the 
objects, so the information was not there in IMM anymore, and the  crashed 
happened.


3. Reproduction 
= = 
Can be reproduced like below: - Disable PBE 1. Create a huge amount of objects 
with one parent object.  2. In my case, I created 2 root objects of two 
different classes with about 100k  child objects each Delete first root object, 
then delete the class associated with this object. 3. Delete second root 
object, delete the class associated with this object. 


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net 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.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets

[tickets] [opensaf:tickets] #2647 ntfd: ntfimcnd crashed on handling for Object creation callback

2017-11-06 Thread Srinivas Siva Mangipudy via Opensaf-tickets

Hi Srinivas

If something that prevents ntfimcn to send notifications happen ntfimcn shall 
be restarted so that a possible missed notification message is sent. If this 
may happen in “normal” situations ntfimcn shall just exit without any coredump. 
Possibly a notification (LOG_NO) should be written to the syslog. If the 
problem is “not normal”, something that should never happen (an error that must 
be analyzed and maybe fixed) an abort is better since it gives us a back-trace 
of what has happened. Before any abort is done an error message shall be 
written to syslog (LOG_ER). This error message should contain information about 
what has happened and where it has happened (__FUNCTION__, __LINE__) in order 
to have at least some information if a coredump is lost, could not be 
genereated, no back-trace was created etc.

So, the question is, is this something that could happen in a “real” system and 
is it of any interest to get a core-dump to analyze the problem? In any case 
ntfimcn will recover.
If the answer is that this event triggering the core-dump is not a fail to 
analyze and that it is something ntfimcn should just gracefully recover from 
then change to LOG_NO + _Exit.

Regards
Lennart

From: Srinivas Mangipudy [mailto:srinivas.mangip...@oracle.com] 
Sent: den 2 november 2017 16:42
To: Lennart Lund ; Minh Hon Chau 

Cc: Ravi Sekhar Reddy Konda 
Subject: RE: OSAF : ntfimcnd core dump issue -- 2647.

Hi Lennart,

Thanks a lot for the explanation.
It was really helpful.

Do you think it is better to log the error and then call _exit  ( we will have 
a graceful restart)  then calling abort and allowing the process to dump core 
in this case?
Please let me know your thoughts about this.

Thanks and best regards
Srinivas


From: Lennart Lund [mailto:lennart.l...@ericsson.com] 
Sent: Thursday, November 2, 2017 6:26 PM
To: Minh Hon Chau ; Srinivas Mangipudy 

Cc: Ravi Sekhar Reddy Konda ; Lennart Lund 

Subject: RE: OSAF : ntfimcnd core dump issue -- 2647.

Hi

Ntfimcn implements a so called “special applier”. This is an IMM applier that 
receives IMM callbacks in the same way as an object implementer or an ordinary 
applier. The difference is that a special applier is not requesting to become 
applier for any special objects or classes. Instead a configuration attribute 
in an object can be given a flag, ATTR_NOTIFY.
The general error handling in ntfimcn is to exit. This will be detected by the 
osafntfd process that then restarts osfafntfimcnd. To notify that this has 
happened (ntfimcn may have “missed” some IMM modifications while it was down) 
ntfimcn always sends a special notification (may have lost notifications 
notification) when it is started. This notification is used by com-sa to 
request com to do a (re)synchronization.
The “normal” way for ntfimcn to exit is by calling _Exit. When something 
happens that should never happen abort() is used instead (a coredump will be 
created).
If something not normal and really bad is done in the system an abort is 
motivated. This means that ntfimcn shall not be made to “defensively” avoid to 
abort (coredump) if the cluster system and IMM is abused. Instead if we want to 
test something like this it shall be accepted that a coredump is created, this 
is not a Fail! However if something like that ntfimcn is not restarted or that 
no “may have lost notification notification” is sent it is to be considered as 
a Fail.
Note: If ntfimcn exist (or abort) the node or ntf as such is not affected. It 
is only the ntfimcn process that is restarted.

Ticket #2647 should probably not be fixed instead it should be set to invalid.

/Lennart

From: Minh Hon Chau [mailto:minh.c...@dektech.com.au] 
Sent: den 2 november 2017 05:45
To: Srinivas Mangipudy 
Cc: Ravi Sekhar Reddy Konda ; Lennart Lund 

Subject: Re: OSAF : ntfimcnd core dump issue -- 2647.

Hi Srinivas,
+ Lennart.
If I understand correctly, the test creates a huge amount of objects (are they 
RT or Config?), and while the callbacks are coming, the test deletes the class. 
The latter callbacks can't find class name so it aborts.
I think we can defensively avoid coredump and not sending notification as your 
suggestion, but I'm wondering the integrity from IMM, as IMM user receives a 
callback but the associated class is not existed.
Thanks,
Minh

On 01/11/17 22:04, Srinivas Mangipudy wrote:
Hi Minh,
 
This is regarding Notification issue 
https://sourceforge.net/p/opensaf/tickets/2647/.
 
This issue is occurring since IMM deleted the objects and ntfimcnd was not able 
to fetch the object, so it returned back “SA_AIS_ERR_NOT_EXIST” error.
Since “SA_AIS_ERR_NOT_EXIST” was returned,  ntfimcnd aborted, leading to core 
dump.
 
I have

[tickets] [opensaf:tickets] #2647 ntfd: ntfimcnd crashed on handling for Object creation callback

2017-10-19 Thread Srinivas Siva Mangipudy via Opensaf-tickets

- Description has changed:

Diff:



--- old
+++ new
@@ -3,7 +3,7 @@
 2. Analysis 
= =
 A huge number of objects, about 200k objects, were created in IMM with PBE 
disabled. Then these objects were deleted in one CCB (by deleting the root 
object). After deleting the objects, the classes were also removed. Then the 
crash happened.
 
-Oct 19 19:45:04 SC-2-1 osafimmnd[22799]: NO Number of objects in IMM is:10 
Oct 19 19:47:00 SC-2-1 osafimmnd[22799]: NO Number of objects in IMM is:20 
Oct 19 19:47:00 SC-2-1 osafimmnd[22799]: NO Ccb 217 COMMITTED (immcfg_SC-2- 
1_27933) Oct 19 19:47:01 SC-2-1 osafimmnd[22799]: WA Busy in HUGE admin owner 
release 5 Oct 19 19:47:01 SC-2-1 osafimmnd[22799]: WA Busy in HUGE admin 
owner release 10 Oct 19 19:47:01 SC-2-1 osafimmnd[22799]: WA Busy in HUGE 
admin owner release 15 Oct 19 19:47:01 SC-2-1 osafimmnd[22799]: WA Busy in 
HUGE admin owner release 20 Oct 19 19:47:25 SC-2-1 osafimmnd[22799]: NO Ccb 
218 COMMITTED (immcfg_SC-2- 1_28075) Oct 19 19:47:25 SC-2-1 
osafntfimcnd[27468]: ER saImmOmClassDescriptionGet_2 failed  
SA_AIS_ERR_NOT_EXIST (12) Oct 19 19:47:25 SC-2-1 osafntfimcnd[27468]:  
../../../../../../../opensaf/osaf/services/saf/ntfsv/ntfimcnd/ntfimcn_imm.c:167:
 get_rdn_attr_name:  Assertion '0' failed. 
+ 
../../../../../../../opensaf/osaf/services/saf/ntfsv/ntfimcnd/ntfimcn_imm.c:167:
 get_rdn_attr_name:  Assertion '0' failed. 
 
 When NTFimcnd created notifications, some information had to be looked up in 
IMM.  
 NTFimcnd only asked for class information in case of object creation: 
@@ -13,9 +13,6 @@
 
 In this case, NTF was still handling notifications for a big number of created 
objects.  Usually,  NTFimcnd cached the class information.  But because these 
objects belong to many classes, it had to ask IMM for class information. But  
the class was already removed in IMM.  IMM was much faster to create and delete 
the objects and class (with PBE disabled), while NTF  was still processing the 
objects, so the information was not there in IMM anymore, and the  crashed 
happened.
 
-Oct 19 19:47:25.344370 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_proc.c:2333] 
TR Ccb-object- create callback Oct 19 19:47:25.344381 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_proc.c:2436] 
TR ccb-object-create  make the callback Oct 19 19:47:25.344385 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/services/saf/ntfsv/ntfimcnd/ntfimcn_imm.c:0426]
 >>  saImmOiCcbObjectCreateCallback Oct 19 19:47:25.344389 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/services/saf/ntfsv/ntfimcnd/ntfimcn_imm.c:0194]
 >>  get_created_dn Oct 19 19:47:25.344392 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/services/saf/ntfsv/ntfimcnd/ntfimcn_imm.c:0105]
 >>  get_rdn_attr_name Oct 19 19:47:25.344398 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_om_api.c:4987]
 >>  saImmOmClassDescriptionGet_2 Oct 19 19:47:25.344402 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_om_api.c:4996]
 >>  saImmOmClassDescriptionGet_2 Oct 19 19:47:25.344407 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_om_api.c:5066]
 TR ClassName:  TestCCB1 Oct 19 19:47:25.344411 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_om_api.c:5083]
 TR  ClassDescrGet 3 Oct 19 19:47:25.344578 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_om_api.c:5121]
 TR Alloc attrdefs  array:0x1933650 Oct 19 19:47:25.344594 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_om_api.c:5327]
 <<  saImmOmClassDescriptionGet_2 Oct 19 19:47:25.344619 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_om_api.c:5335]
 >>  saImmOmClassDescriptionMemoryFree_2 
-Oct 19 19:47:25.344625 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_om_api.c:5379]
 <<  saImmOmClassDescriptionMemoryFree_2 Oct 19 19:47:25.344628 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/services/saf/ntfsv/ntfimcnd/ntfimcn_imm.c:0164]
 <<  get_rdn_attr_name Oct 19 19:47:25.344633 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/services/saf/ntfsv/ntfimcnd/ntfimcn_imm.c:0228]
 <<  get_created_dn Oct 19 19:47:25.344639 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/services/saf/ntfsv/ntfimcnd/ntfimcn_imm.c:0473]
 <<  saImmOiCcbObjectCreateCallback Oct 19 19:47:25.344643 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_proc.c:2496] 
TR ccb-object-create  callback returned RC:1 Oct 19 19:47:25.344648 
osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_proc.c:3171] 
<<  imma_process_callback_info Oct 19 19:47:25.344653 osafntfimcnd

[tickets] [opensaf:tickets] #2647 ntfd: ntfimcnd crashed on handling for Object creation callback

2017-10-19 Thread Srinivas Siva Mangipudy via Opensaf-tickets

- Description has changed:

Diff:



--- old
+++ new
@@ -1,4 +1,21 @@
-1. Problem 
= = 
NTFimcnd crashed while 200k objects was created and the deleted in IMM, the 
classes  associated with these objects were also removed. 2. Analysis 
= = A 
huge number of objects, about 200k objects, were created in IMM with PBE 
disabled. Then these objects were deleted in one CCB (by deleting the root 
object). After deleting the objects, the classes were also removed. Then the 
crash happened. Oct 19 19:45:04 SC-2-1 osafimmnd[22799]: NO Number of objects 
in IMM is:10 Oct 19 19:47:00 SC-2-1 osafimmnd[22799]: NO Number of objects 
in IMM is:20 Oct 19 19:47:00 SC-2-1 osafimmnd[22799]: NO Ccb 217 COMMITTED 
(immcfg_SC-2- 1_27933) Oct 19 19:47:01 SC-2-1 osafimmnd[22799]: WA Busy in HUGE 
admin owner release 5 Oct 19 19:47:01 SC-2-1 osafimmnd[22799]: WA Busy in 
HUGE admin owner release 10 Oct 19 19:47:01 SC-2-1 osafimmnd[22799]: WA 
Busy in HUGE admin owner release 15 Oct 19 19:47:01 SC-2-1 
osafimmnd[22799]: WA Busy in HUGE admin owner release 20 Oct 19 19:47:25 
SC-2-1 osafimmnd[22799]: NO Ccb 218 COMMITTED (immcfg_SC-2- 1_28075) Oct 19 
19:47:25 SC-2-1 osafntfimcnd[27468]: ER saImmOmClassDescriptionGet_2 failed  
SA_AIS_ERR_NOT_EXIST (12) Oct 19 19:47:25 SC-2-1 osafntfimcnd[27468]:  
../../../../../../../opensaf/osaf/services/saf/ntfsv/ntfimcnd/ntfimcn_imm.c:167:
 get_rdn_attr_name:  Assertion '0' failed. When NTFimcnd created notifications, 
some information had to be looked up in IMM.  NTFimcnd only asked for class 
information in case of object creation: static SaAisErrorT 
saImmOiCcbObjectCreateCallback(SaImmOiHandleT immOiHandle,  
  SaImmOiCcbIdT ccbId,  
  const SaImmClassNameT className,  
  const SaNameT *parentName, const SaImmAttrValuesT_2 **attr) { … 
dn_ptr = get_created_dn(className, parentName, attr); … } static void 
saImmOiCcbApplyCallback(SaImmOiHandleT immOiHandle, SaImmOiCcbIdT ccbId) {  
   … switch 
(ccbUtilOperationData->operationType) { case CCBUTIL_CREATE:
 rdn_attr_name = get_rdn_attr_name( 
ccbUtilOperationData- >param.create.className); 
-internal_rc = ntfimcn_send_object_create_notification( 
ccbUtilOperationData, rdn_attr_name,
 ccbLast); … } In this case, NTF was still 
handling notifications for a big number of created objects.  Usually,  NTFimcnd 
cached the class information.  But because these objects belong to many 
classes, it had to ask IMM for class information. But  the class was already 
removed in IMM.  IMM was much faster to create and delete the objects and class 
(with PBE disabled), while NTF  was still processing the objects, so the 
information was not there in IMM anymore, and the  crashed happened. Oct 19 
19:47:25.344370 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_proc.c:2333] 
TR Ccb-object- create callback Oct 19 19:47:25.344381 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_proc.c:2436] 
TR ccb-object-create  make the callback Oct 19 19:47:25.344385 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/services/saf/ntfsv/ntfimcnd/ntfimcn_imm.c:0426]
 >>  saImmOiCcbObjectCreateCallback Oct 19 19:47:25.344389 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/services/saf/ntfsv/ntfimcnd/ntfimcn_imm.c:0194]
 >>  get_created_dn Oct 19 19:47:25.344392 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/services/saf/ntfsv/ntfimcnd/ntfimcn_imm.c:0105]
 >>  get_rdn_attr_name Oct 19 19:47:25.344398 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_om_api.c:4987]
 >>  saImmOmClassDescriptionGet_2 Oct 19 19:47:25.344402 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_om_api.c:4996]
 >>  saImmOmClassDescriptionGet_2 Oct 19 19:47:25.344407 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_om_api.c:5066]
 TR ClassName:  TestCCB1 Oct 19 19:47:25.344411 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_om_api.c:5083]
 TR  ClassDescrGet 3 Oct 19 19:47:25.344578 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_om_api.c:5121]
 TR Alloc attrdefs  array:0x1933650 Oct 19 19:47:25.344594 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_om_api.c:5327]
 <<  saImmOmClassDescriptionGet_2 Oct 19 19:47:25.344619 osafntfimcnd

[tickets] [opensaf:tickets] #2647 ntfd: ntfimcnd crashed on handling for Object creation callback

2017-10-19 Thread Srinivas Siva Mangipudy via Opensaf-tickets




---

** [tickets:#2647] ntfd: ntfimcnd crashed on handling for Object creation 
callback**

**Status:** unassigned
**Milestone:** 5.17.10
**Created:** Thu Oct 19, 2017 12:45 PM UTC by Srinivas Siva Mangipudy
**Last Updated:** Thu Oct 19, 2017 12:45 PM UTC
**Owner:** nobody


1. Problem 
= = 
NTFimcnd crashed while 200k objects was created and the deleted in IMM, the 
classes  associated with these objects were also removed. 2. Analysis 
= = A 
huge number of objects, about 200k objects, were created in IMM with PBE 
disabled. Then these objects were deleted in one CCB (by deleting the root 
object). After deleting the objects, the classes were also removed. Then the 
crash happened. Oct 19 19:45:04 SC-2-1 osafimmnd[22799]: NO Number of objects 
in IMM is:10 Oct 19 19:47:00 SC-2-1 osafimmnd[22799]: NO Number of objects 
in IMM is:20 Oct 19 19:47:00 SC-2-1 osafimmnd[22799]: NO Ccb 217 COMMITTED 
(immcfg_SC-2- 1_27933) Oct 19 19:47:01 SC-2-1 osafimmnd[22799]: WA Busy in HUGE 
admin owner release 5 Oct 19 19:47:01 SC-2-1 osafimmnd[22799]: WA Busy in 
HUGE admin owner release 10 Oct 19 19:47:01 SC-2-1 osafimmnd[22799]: WA 
Busy in HUGE admin owner release 15 Oct 19 19:47:01 SC-2-1 
osafimmnd[22799]: WA Busy in HUGE admin owner release 20 Oct 19 19:47:25 
SC-2-1 osafimmnd[22799]: NO Ccb 218 COMMITTED (immcfg_SC-2- 1_28075) Oct 19 
19:47:25 SC-2-1 osafntfimcnd[27468]: ER saImmOmClassDescriptionGet_2 failed  
SA_AIS_ERR_NOT_EXIST (12) Oct 19 19:47:25 SC-2-1 osafntfimcnd[27468]:  
../../../../../../../opensaf/osaf/services/saf/ntfsv/ntfimcnd/ntfimcn_imm.c:167:
 get_rdn_attr_name:  Assertion '0' failed. When NTFimcnd created notifications, 
some information had to be looked up in IMM.  NTFimcnd only asked for class 
information in case of object creation: static SaAisErrorT 
saImmOiCcbObjectCreateCallback(SaImmOiHandleT immOiHandle,  
  SaImmOiCcbIdT ccbId,  
  const SaImmClassNameT className,  
  const SaNameT *parentName, const SaImmAttrValuesT_2 **attr) { … 
dn_ptr = get_created_dn(className, parentName, attr); … } static void 
saImmOiCcbApplyCallback(SaImmOiHandleT immOiHandle, SaImmOiCcbIdT ccbId) {  
   … switch 
(ccbUtilOperationData->operationType) { case CCBUTIL_CREATE:
 rdn_attr_name = get_rdn_attr_name( 
ccbUtilOperationData- >param.create.className); 
internal_rc = ntfimcn_send_object_create_notification(  
   ccbUtilOperationData, rdn_attr_name, 
ccbLast); … } In this case, NTF was still 
handling notifications for a big number of created objects.  Usually,  NTFimcnd 
cached the class information.  But because these objects belong to many 
classes, it had to ask IMM for class information. But  the class was already 
removed in IMM.  IMM was much faster to create and delete the objects and class 
(with PBE disabled), while NTF  was still processing the objects, so the 
information was not there in IMM anymore, and the  crashed happened. Oct 19 
19:47:25.344370 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_proc.c:2333] 
TR Ccb-object- create callback Oct 19 19:47:25.344381 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_proc.c:2436] 
TR ccb-object-create  make the callback Oct 19 19:47:25.344385 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/services/saf/ntfsv/ntfimcnd/ntfimcn_imm.c:0426]
 >>  saImmOiCcbObjectCreateCallback Oct 19 19:47:25.344389 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/services/saf/ntfsv/ntfimcnd/ntfimcn_imm.c:0194]
 >>  get_created_dn Oct 19 19:47:25.344392 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/services/saf/ntfsv/ntfimcnd/ntfimcn_imm.c:0105]
 >>  get_rdn_attr_name Oct 19 19:47:25.344398 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_om_api.c:4987]
 >>  saImmOmClassDescriptionGet_2 Oct 19 19:47:25.344402 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_om_api.c:4996]
 >>  saImmOmClassDescriptionGet_2 Oct 19 19:47:25.344407 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_om_api.c:5066]
 TR ClassName:  TestCCB1 Oct 19 19:47:25.344411 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_om_api.c:5083]
 TR  ClassDescrGet 3 Oct 19 19:47:25.344578 osafntfimcnd  
[27468:../../../../../../../opensaf/osaf/libs/agents/saf/imma/imma_om_api.c:5121]
 TR Alloc attrdefs  array:0x1933650 Oct 19 19:47:25.344594 osafntfimcnd

[tickets] [opensaf:tickets] #2647 ntfd: ntfimcnd crashed on handling for Object creation callback

[tickets] [opensaf:tickets] #2647 ntfd: ntfimcnd crashed on handling for Object creation callback

[tickets] [opensaf:tickets] #2647 ntfd: ntfimcnd crashed on handling for Object creation callback

[tickets] [opensaf:tickets] #2647 ntfd: ntfimcnd crashed on handling for Object creation callback

[tickets] [opensaf:tickets] #2647 ntfd: ntfimcnd crashed on handling for Object creation callback

[tickets] [opensaf:tickets] #2647 ntfd: ntfimcnd crashed on handling for Object creation callback

6 matches

Site Navigation

Mail list logo

Footer information