Hi Hans,
This function is added in this release and in enhancement #1725
changeset 7962.
When AMFD recreates all the SUSIs and COMPCSI from state info, it tries
to clean up all stale compcsis in IMM. In this function it checks if for
every compcsi it reads from IMM its SU, SI and SUSI should be present in
the AMFD db.
In this particular assert comp is not found in AMFD db.
Just interested to know in which case this assertion occurred.
Is this occured when some configuration was being deleted and system
became headless? So after headless this comp was not found.
Thanks,
Praveen
On 29-Sep-16 2:02 PM, Hans Nordeback wrote:
> osaf/services/saf/amf/amfd/csi.cc | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
>
> Causes cyclic reboot of SC-1 during resilience testing
>
> diff --git a/osaf/services/saf/amf/amfd/csi.cc
> b/osaf/services/saf/amf/amfd/csi.cc
> --- a/osaf/services/saf/amf/amfd/csi.cc
> +++ b/osaf/services/saf/amf/amfd/csi.cc
> @@ -1585,8 +1585,10 @@ void avd_compcsi_cleanup_imm_object(AVD_
> SaNameT comp_name;
> avsv_sanamet_init_from_association_dn(&dn, &comp_name,
> "safComp", csi->name.c_str());
> AVD_COMP *comp = comp_db->find(Amf::to_string(&comp_name));
> + if (comp == nullptr) {
> + LOG_WA("Component %s not found in comp_db",
> osaf_extended_name_borrow(&comp_name));
> + }
> osaf_extended_name_free(&comp_name);
> - osafassert(comp);
>
> susi = avd_susi_find(avd_cb, comp->su->name, si->name);
> if (susi == nullptr || (susi->fsm == AVD_SU_SI_STATE_ABSENT)) {
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Opensaf-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
