[tickets] [opensaf:tickets] #2146 log: implement SaLogFilterSetCallbackT
- **assigned_to**: Vu Minh Nguyen --> Canh Truong --- ** [tickets:#2146] log: implement SaLogFilterSetCallbackT** **Status:** assigned **Milestone:** 5.2.FC **Created:** Fri Oct 28, 2016 09:01 AM UTC by Vu Minh Nguyen **Last Updated:** Fri Oct 28, 2016 09:01 AM UTC **Owner:** Canh Truong This ticket is to implement SaLogFilterSetCallbackT which is mentioned at section `3.6.5 SaLogFilterSetCallbackT` @ AIS LOG document. --- 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.-- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #2172 mbc: trace logs of OpenSAF services are flooded after si-swap
- **summary**: mbc: service TRACE logs are flooded after si-swap --> mbc: trace logs of OpenSAF services are flooded after si-swap --- ** [tickets:#2172] mbc: trace logs of OpenSAF services are flooded after si-swap** **Status:** unassigned **Milestone:** 5.0.2 **Created:** Mon Nov 07, 2016 07:19 AM UTC by Vu Minh Nguyen **Last Updated:** Mon Nov 07, 2016 07:19 AM UTC **Owner:** nobody After performing si-swap, OpenSAF service TRACE are flooded by MBCSV TRACE log. Following TRACE are dumped at every second, and seems non-stop: > Nov 7 10:48:42.136763 osaflogd [453:mbcsv_api.c:0406] >> > mbcsv_process_dispatch_request: Dispatch MBCSV event > Nov 7 10:48:42.137051 osaflogd [453:mbcsv_pr_evts.c:0269] >> > mbcsv_hdl_dispatch_all > Nov 7 10:48:42.137301 osaflogd [453:mbcsv_pr_evts.c:0068] >> > mbcsv_process_events: mbcsv hdl: 4293918753 > Nov 7 10:48:42.137504 osaflogd [453:mbcsv_pr_evts.c:0129] TR Timer event > Nov 7 10:48:42.137590 osaflogd [453:mbcsv_pr_evts.c:0140] T1 myrole: 1, > svc_id: 36, pwe_hdl: 65547, peer_anchor: 565214255040142, peer_state: 3, > event type:MBCSV_TMR_TRANSMIT > Nov 7 10:48:42.137670 osaflogd [453:mbcsv_tmr.c:0481] TR Transmit timer. > sending call-again-event for pwe_hdl:65547. revisit! > Nov 7 10:48:42.137750 osaflogd [453:mbcsv_util.c:0929] >> mbcsv_send_msg: > event type: 6 > Nov 7 10:48:42.137826 osaflogd [453:mbcsv_util.c:0811] >> > ncs_mbcsv_encode_message > Nov 7 10:48:42.138089 osaflogd [453:mbcsv_util.c:0832] TR set > call_again_action for coldsync_resp or warmsync_resp or data_resp > Nov 7 10:48:42.138192 osaflogd [453:mbcsv_util.c:0862] TR set-next > call_again_action for coldsync_resp or warmsync_resp or data_resp > Nov 7 10:48:42.138363 osaflogd [453:mbcsv_util.c:0905] << > ncs_mbcsv_encode_message > Nov 7 10:48:42.138453 osaflogd [453:mbcsv_mds.c:0185] >> mbcsv_mds_send_msg: > sending to vdest:b > Nov 7 10:48:42.138593 osaflogd [453:mbcsv_mds.c:0201] TR send type > MDS_SENDTYPE_RED > Nov 7 10:48:42.139412 osaflogd [453:mbcsv_mds.c:0244] << mbcsv_mds_send_msg: > success > Nov 7 10:48:42.139614 osaflogd [453:mbcsv_util.c:0978] T1 event is > multi-part response(i.e.coldsync resp, warmsync resp or dataresp), call-again > Nov 7 10:48:42.139704 osaflogd [453:mbcsv_util.c:0982] T1 start the transmit > timer > Nov 7 10:48:42.139782 osaflogd [453:mbcsv_tmr.c:0094] >> > ncs_mbcsv_start_timer > Nov 7 10:48:42.140069 osaflogd [453:mbcsv_tmr.c:0120] TR starting timer. my > role:1, svc_id:36, pwe_hdl:65547, peer_anchor: 565214255040142, tmr > type:NCS_MBCSV_TMR_TRANSMIT > Nov 7 10:48:42.140568 osaflogd [453:mbcsv_tmr.c:0127] << > ncs_mbcsv_start_timer > Nov 7 10:48:42.140665 osaflogd [453:mbcsv_util.c:0999] << mbcsv_send_msg > Nov 7 10:48:42.140746 osaflogd [453:mbcsv_pr_evts.c:0222] << > mbcsv_process_events > Nov 7 10:48:42.141440 osaflogd [453:mbcsv_pr_evts.c:0278] << > mbcsv_hdl_dispatch_all > Nov 7 10:48:42.141648 osaflogd [453:mbcsv_api.c:0435] << > mbcsv_process_dispatch_request: retval: 1 --- 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.-- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #2172 mbc: service TRACE logs are flooded after si-swap
--- ** [tickets:#2172] mbc: service TRACE logs are flooded after si-swap** **Status:** unassigned **Milestone:** 5.0.2 **Created:** Mon Nov 07, 2016 07:19 AM UTC by Vu Minh Nguyen **Last Updated:** Mon Nov 07, 2016 07:19 AM UTC **Owner:** nobody After performing si-swap, OpenSAF service TRACE are flooded by MBCSV TRACE log. Following TRACE are dumped at every second, and seems non-stop: > Nov 7 10:48:42.136763 osaflogd [453:mbcsv_api.c:0406] >> > mbcsv_process_dispatch_request: Dispatch MBCSV event > Nov 7 10:48:42.137051 osaflogd [453:mbcsv_pr_evts.c:0269] >> > mbcsv_hdl_dispatch_all > Nov 7 10:48:42.137301 osaflogd [453:mbcsv_pr_evts.c:0068] >> > mbcsv_process_events: mbcsv hdl: 4293918753 > Nov 7 10:48:42.137504 osaflogd [453:mbcsv_pr_evts.c:0129] TR Timer event > Nov 7 10:48:42.137590 osaflogd [453:mbcsv_pr_evts.c:0140] T1 myrole: 1, > svc_id: 36, pwe_hdl: 65547, peer_anchor: 565214255040142, peer_state: 3, > event type:MBCSV_TMR_TRANSMIT > Nov 7 10:48:42.137670 osaflogd [453:mbcsv_tmr.c:0481] TR Transmit timer. > sending call-again-event for pwe_hdl:65547. revisit! > Nov 7 10:48:42.137750 osaflogd [453:mbcsv_util.c:0929] >> mbcsv_send_msg: > event type: 6 > Nov 7 10:48:42.137826 osaflogd [453:mbcsv_util.c:0811] >> > ncs_mbcsv_encode_message > Nov 7 10:48:42.138089 osaflogd [453:mbcsv_util.c:0832] TR set > call_again_action for coldsync_resp or warmsync_resp or data_resp > Nov 7 10:48:42.138192 osaflogd [453:mbcsv_util.c:0862] TR set-next > call_again_action for coldsync_resp or warmsync_resp or data_resp > Nov 7 10:48:42.138363 osaflogd [453:mbcsv_util.c:0905] << > ncs_mbcsv_encode_message > Nov 7 10:48:42.138453 osaflogd [453:mbcsv_mds.c:0185] >> mbcsv_mds_send_msg: > sending to vdest:b > Nov 7 10:48:42.138593 osaflogd [453:mbcsv_mds.c:0201] TR send type > MDS_SENDTYPE_RED > Nov 7 10:48:42.139412 osaflogd [453:mbcsv_mds.c:0244] << mbcsv_mds_send_msg: > success > Nov 7 10:48:42.139614 osaflogd [453:mbcsv_util.c:0978] T1 event is > multi-part response(i.e.coldsync resp, warmsync resp or dataresp), call-again > Nov 7 10:48:42.139704 osaflogd [453:mbcsv_util.c:0982] T1 start the transmit > timer > Nov 7 10:48:42.139782 osaflogd [453:mbcsv_tmr.c:0094] >> > ncs_mbcsv_start_timer > Nov 7 10:48:42.140069 osaflogd [453:mbcsv_tmr.c:0120] TR starting timer. my > role:1, svc_id:36, pwe_hdl:65547, peer_anchor: 565214255040142, tmr > type:NCS_MBCSV_TMR_TRANSMIT > Nov 7 10:48:42.140568 osaflogd [453:mbcsv_tmr.c:0127] << > ncs_mbcsv_start_timer > Nov 7 10:48:42.140665 osaflogd [453:mbcsv_util.c:0999] << mbcsv_send_msg > Nov 7 10:48:42.140746 osaflogd [453:mbcsv_pr_evts.c:0222] << > mbcsv_process_events > Nov 7 10:48:42.141440 osaflogd [453:mbcsv_pr_evts.c:0278] << > mbcsv_hdl_dispatch_all > Nov 7 10:48:42.141648 osaflogd [453:mbcsv_api.c:0435] << > mbcsv_process_dispatch_request: retval: 1 --- 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.-- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #245 amf: saAmfComponentErrorClear_4() does not returns SA_AIS_ERR_NO_OP for operationally enabled comp.
- **status**: accepted --> review --- ** [tickets:#245] amf: saAmfComponentErrorClear_4() does not returns SA_AIS_ERR_NO_OP for operationally enabled comp.** **Status:** review **Milestone:** 5.2.FC **Created:** Thu May 16, 2013 06:37 AM UTC by Praveen **Last Updated:** Mon Nov 07, 2016 05:56 AM UTC **Owner:** Nagendra Kumar Migrated from http://devel.opensaf.org/ticket/2818. Changeset:3728 When saAmfComponentErrorClear_4() is called for an operationally enabled component, it returns SA_AIS_OK. According to spec (B.04.01, section 7.12.2 page 329)return value should be SA_AIS_ERR_NO_OP. --- 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.-- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #245 amf: saAmfComponentErrorClear_4() does not returns SA_AIS_ERR_NO_OP for operationally enabled comp.
- **status**: unassigned --> accepted - **assigned_to**: Nagendra Kumar - **Part**: - --> nd - **Milestone**: future --> 5.2.FC --- ** [tickets:#245] amf: saAmfComponentErrorClear_4() does not returns SA_AIS_ERR_NO_OP for operationally enabled comp.** **Status:** accepted **Milestone:** 5.2.FC **Created:** Thu May 16, 2013 06:37 AM UTC by Praveen **Last Updated:** Thu Aug 06, 2015 11:09 AM UTC **Owner:** Nagendra Kumar Migrated from http://devel.opensaf.org/ticket/2818. Changeset:3728 When saAmfComponentErrorClear_4() is called for an operationally enabled component, it returns SA_AIS_OK. According to spec (B.04.01, section 7.12.2 page 329)return value should be SA_AIS_ERR_NO_OP. --- 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.-- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #248 "amf: Incorrect return code from saAmfComponentErrorReport_4 () and saAmfComponentErrorClear_4()".
- **status**: accepted --> invalid
- **Comment**:
Tested on CS #8019. Amf return BAD_HANDLE. Below is the test case code snippet:
1. SaNtfCorrelationIdsT *corr_ids=malloc(sizeof(SaNtfCorrelationIdsT));
corr_ids->rootCorrelationId = SA_NTF_IDENTIFIER_UNUSED;
corr_ids->parentCorrelationId = SA_NTF_IDENTIFIER_UNUSED;
rc = saAmfComponentErrorReport_4(my_amf_hdl, _comp_name, 0,
SA_AMF_COMPONENT_RESTART, corr_ids);
if (rc != SA_AIS_OK) {
syslog(LOG_ERR, "1.saAmfComponentErrorReport FAILED - %u", rc);
} else
syslog(LOG_ERR, "1. saAmfComponentErrorReport Success - %u",
rc);
--
2. syslog(LOG_ERR, "= Calling Err Clear ");
SaNtfCorrelationIdsT *corr_ids=malloc(sizeof(SaNtfCorrelationIdsT));
corr_ids->rootCorrelationId = SA_NTF_IDENTIFIER_UNUSED;
corr_ids->parentCorrelationId = SA_NTF_IDENTIFIER_UNUSED;
rc = saAmfComponentErrorClear_4(my_amf_hdl, _comp_name,
corr_ids);
if (rc != SA_AIS_OK) {
syslog(LOG_ERR, "1.saAmfComponentErrorClear FAILED - %u", rc);
} else
syslog(LOG_ERR, "1. saAmfComponentErrorClear Success - %u", rc);
The result:
1. Nov 7 10:55:14 PM_SC-1 amf_demo[4843]: saAmfFinalize Success - 1
Nov 7 10:55:14 PM_SC-1 amf_demo[4843]: = Calling Err Rep
Nov 7 10:55:14 PM_SC-1 amf_demo[4843]: saAmfComponentErrorReport FAILED - 9
2. Nov 7 11:08:17 PM_SC-1 amf_demo[7798]: saAmfFinalize Success - 1
Nov 7 11:08:17 PM_SC-1 amf_demo[7798]: = Calling Err Clear
Nov 7 11:08:17 PM_SC-1 amf_demo[7798]: 1.saAmfComponentErrorClear FAILED - 9
So, closing this ticket.
---
** [tickets:#248] "amf: Incorrect return code from saAmfComponentErrorReport_4
() and saAmfComponentErrorClear_4()". **
**Status:** invalid
**Milestone:** 5.2.FC
**Created:** Thu May 16, 2013 06:41 AM UTC by Praveen
**Last Updated:** Fri Nov 04, 2016 12:12 PM UTC
**Owner:** Nagendra Kumar
Migrated from http://devel.opensaf.org/ticket/2817.
Changeset:3728
When saAmfComponentErrorReport_4() and saAmfComponentErrorReport_4() are
called after finalizing the amfHandle(calling saAmfFinalize()), both of them
returns SA_AIS_ERR_VERSION instead of SA_AIS_ERR_BAD_HANDLE.
---
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.--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] Re: #2162 AMF: Headless recovery failed if SC failover during headless sync
attach c1.tgz --- ** [tickets:#2162] AMF: Headless recovery failed if SC failover during headless sync** **Status:** assigned **Milestone:** 5.2.FC **Labels:** headless recovery **Created:** Thu Nov 03, 2016 11:01 AM UTC by Minh Hon Chau **Last Updated:** Mon Nov 07, 2016 05:11 AM UTC **Owner:** Minh Hon Chau **Attachments:** - [log.tgz](https://sourceforge.net/p/opensaf/tickets/2162/attachment/log.tgz) (1.4 MB; application/x-compressed) Test steps: - Set up 2N assignment, PL4 hosts SU4 (active assignment), PL5 host SU5 (standby assignment) - Stop SCs - Stop PL4 - Restart SC1 - Restart SC2 - Since PL4 is stopped, headless sync will be time out in 10 secs. During this 10 secs, reboot SC1 to trigger SC failover Observation: SC2 becomes active controller, cold sync complete, but SU5 still has standby assignment. When SC2 becomes active controller, the part of code that performs headless recovery is not executed (function failover_absent_assignment()). Therefore, the transient assignments remain after SC failover. Log/trace are attached. --- 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.-- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #2169 amf: su containing proxy comps is not working properly after a su restart recovery
- **status**: unassigned --> assigned - **assigned_to**: Nagendra Kumar --- ** [tickets:#2169] amf: su containing proxy comps is not working properly after a su restart recovery** **Status:** assigned **Milestone:** 5.0.2 **Created:** Fri Nov 04, 2016 09:45 AM UTC by Long HB Nguyen **Last Updated:** Fri Nov 04, 2016 09:45 AM UTC **Owner:** Nagendra Kumar **Attachments:** - [osaftestLog-2016-11-04_14-55-08.tgz](https://sourceforge.net/p/opensaf/tickets/2169/attachment/osaftestLog-2016-11-04_14-55-08.tgz) (1.2 MB; application/x-gzip-compressed) - Description: When a proxy component restart is escalated to a su restart, then the SU is not working properly after that (e.g. lock failed). - Reproduction: 1) Use the proxy demo in amf samples. 2) Unlock-in/unlock proxy SU, proxied SU. 3) Kill the proxy process some times to take the recovery escalation from comp restart to su restart. 4) Lock the proxy SU => timeout. --- 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.-- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #2162 AMF: Headless recovery failed if SC failover during headless sync
A simple start up sequence after headless as in 2162.seq, 3 major cases that SC-1 can down from start up till headless recovery: 1- SC1 goes down before SC2 is successfully indicated as standby controller, which happens before standby assignment for 2N Opensaf SU 2- SC2 is standby controller, SC1 goes down before SC2 complete cold sync 3- SC2 completes cold sync, SC1 goes down before cluster initiation is done/timeout If case 2 happens, SC2 is rebooted as expected result today Case 1 is reproduced, see attached file c1.tgz, the result is that SC2 gets stuck in receiving node_up msg from all nodes, the cause is 2N Opensaf SU in SC2 could not be assigned as active Case 3 is primarily reported in this ticket. Attachments: - [2162.seq](https://sourceforge.net/p/opensaf/tickets/_discuss/thread/f093e418/493c/attachment/2162.seq) (1.9 kB; application/octet-stream) --- ** [tickets:#2162] AMF: Headless recovery failed if SC failover during headless sync** **Status:** assigned **Milestone:** 5.2.FC **Labels:** headless recovery **Created:** Thu Nov 03, 2016 11:01 AM UTC by Minh Hon Chau **Last Updated:** Thu Nov 03, 2016 11:01 AM UTC **Owner:** Minh Hon Chau **Attachments:** - [log.tgz](https://sourceforge.net/p/opensaf/tickets/2162/attachment/log.tgz) (1.4 MB; application/x-compressed) Test steps: - Set up 2N assignment, PL4 hosts SU4 (active assignment), PL5 host SU5 (standby assignment) - Stop SCs - Stop PL4 - Restart SC1 - Restart SC2 - Since PL4 is stopped, headless sync will be time out in 10 secs. During this 10 secs, reboot SC1 to trigger SC failover Observation: SC2 becomes active controller, cold sync complete, but SU5 still has standby assignment. When SC2 becomes active controller, the part of code that performs headless recovery is not executed (function failover_absent_assignment()). Therefore, the transient assignments remain after SC failover. Log/trace are attached. --- 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.-- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #2171 amfd: invalid reads reported by valgrind
--- ** [tickets:#2171] amfd: invalid reads reported by valgrind** **Status:** unassigned **Milestone:** 5.1.1 **Created:** Sun Nov 06, 2016 11:47 PM UTC by Gary Lee **Last Updated:** Sun Nov 06, 2016 11:47 PM UTC **Owner:** nobody ==492== Invalid read of size 8 ==492==at 0x5FF0B6E: std::_Rb_tree_increment(std::_Rb_tree_node_base const*) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19) ==492==by 0x407617: operator++ (stl_tree.h:278) ==492==by 0x407617: handle_event_in_failover_state (main.cc:424) ==492==by 0x407617: main_loop (main.cc:695) ==492==by 0x407617: main (main.cc:849) ==492== Address 0x83cb0e8 is 8 bytes inside a block of size 48 free'd ==492==at 0x4C2C2BC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==492==by 0x445238: deallocate (new_allocator.h:110) ==492==by 0x445238: _M_put_node (stl_tree.h:374) ==492==by 0x445238: _M_destroy_node (stl_tree.h:422) ==492==by 0x445238: _M_erase_aux (stl_tree.h:1746) ==492==by 0x445238: erase (stl_tree.h:809) ==492==by 0x445238: _M_erase_aux (stl_tree.h:1760) ==492==by 0x445238: erase (stl_tree.h:842) ==492==by 0x445238: erase (stl_tree.h:1771) ==492==by 0x445238: erase (stl_map.h:727) ==492==by 0x445238: erase (amf_db_template.h:119) ==492==by 0x445238: avd_node_delete_nodeid(AVD_AVND*) (node.cc:63) ==492==by 0x440FFC: avd_node_failover(AVD_AVND*) (ndproc.cc:1144) ==492==by 0x407656: handle_event_in_failover_state (main.cc:439) ==492==by 0x407656: main_loop (main.cc:695) ==492==by 0x407656: main (main.cc:849) --- 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.-- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #2170 amfnd: invalid reads reported by valgrind
--- ** [tickets:#2170] amfnd: invalid reads reported by valgrind** **Status:** unassigned **Milestone:** 5.1.1 **Created:** Sun Nov 06, 2016 11:41 PM UTC by Gary Lee **Last Updated:** Sun Nov 06, 2016 11:41 PM UTC **Owner:** nobody ==438== Thread 1: ==438== Invalid read of size 8 ==438==at 0x408380: avnd_evt_tmr_cbk_resp_evh(avnd_cb_tag*, avnd_evt_tag*) (cbq.cc:597) ==438==by 0x42691E: avnd_evt_process (main.cc:626) ==438==by 0x42691E: avnd_main_process() (main.cc:577) ==438==by 0x4058F2: main (main.cc:202) ==438== Address 0x6d260f0 is 64 bytes inside a block of size 88 free'd ==438==at 0x4C2C2BC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==438==by 0x406DDF: avnd_comp_cbq_rec_del(avnd_cb_tag*, avnd_comp_tag*, avnd_cbk_tag*) (cbq.cc:974) ==438==by 0x406FBC: avnd_comp_cbq_rec_pop_and_del(avnd_cb_tag*, avnd_comp_tag*, avnd_cbk_tag*, bool) (cbq.cc:889) ==438==by 0x40837F: avnd_evt_tmr_cbk_resp_evh(avnd_cb_tag*, avnd_evt_tag*) (cbq.cc:597) ==438==by 0x42691E: avnd_evt_process (main.cc:626) ==438==by 0x42691E: avnd_main_process() (main.cc:577) ==438==by 0x4058F2: main (main.cc:202) ==439== Thread 1: ==439== Invalid read of size 8 ==439==at 0x42E700: avnd_silist_getprev(avnd_su_si_rec const*) (sidb.cc:114) ==439==by 0x437A42: avnd_su_si_oper_done(avnd_cb_tag*, avnd_su_tag*, avnd_su_si_rec*) (susm.cc:1098) ==439==by 0x436532: avnd_su_pres_st_chng_prc (susm.cc:1857) ==439==by 0x436532: avnd_su_pres_fsm_run(avnd_cb_tag*, avnd_su_tag*, avnd_comp_tag*, avnd_su_pres_fsm_ev) (susm.cc:1501) ==439==by 0x40C21B: avnd_comp_clc_st_chng_prc(avnd_cb_tag*, avnd_comp_tag*, SaAmfPresenceStateT, SaAmfPresenceStateT) (clc.cc:1460) ==439==by 0x40F48F: avnd_comp_clc_fsm_run(avnd_cb_tag*, avnd_comp_tag*, avnd_comp_clc_pres_fsm_ev) (clc.cc:906) ==439==by 0x40FD49: avnd_evt_clc_resp_evh(avnd_cb_tag*, avnd_evt_tag*) (clc.cc:414) ==439==by 0x42691E: avnd_evt_process (main.cc:626) ==439==by 0x42691E: avnd_main_process() (main.cc:577) ==439==by 0x4058F2: main (main.cc:202) ==439== Address 0x6d20ad0 is 32 bytes inside a block of size 152 free'd ==439==at 0x4C2C2BC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==439==by 0x42FEE8: avnd_su_si_rec_del(avnd_cb_tag*, std::string const&, std::string const&) (sidb.cc:751) ==439==by 0x4375F4: avnd_su_si_oper_done(avnd_cb_tag*, avnd_su_tag*, avnd_su_si_rec*) (susm.cc:1139) ==439==by 0x436859: avnd_su_pres_st_chng_prc (susm.cc:1938) ==439==by 0x436859: avnd_su_pres_fsm_run(avnd_cb_tag*, avnd_su_tag*, avnd_comp_tag*, avnd_su_pres_fsm_ev) (susm.cc:1501) ==439==by 0x438B41: avnd_su_si_remove(avnd_cb_tag*, avnd_su_tag*, avnd_su_si_rec*) (susm.cc:823) ==439==by 0x437A16: avnd_su_si_oper_done(avnd_cb_tag*, avnd_su_tag*, avnd_su_si_rec*) (susm.cc:1099) ==439==by 0x436532: avnd_su_pres_st_chng_prc (susm.cc:1857) ==439==by 0x436532: avnd_su_pres_fsm_run(avnd_cb_tag*, avnd_su_tag*, avnd_comp_tag*, avnd_su_pres_fsm_ev) (susm.cc:1501) ==439==by 0x40C21B: avnd_comp_clc_st_chng_prc(avnd_cb_tag*, avnd_comp_tag*, SaAmfPresenceStateT, SaAmfPresenceStateT) (clc.cc:1460) ==439==by 0x40F48F: avnd_comp_clc_fsm_run(avnd_cb_tag*, avnd_comp_tag*, avnd_comp_clc_pres_fsm_ev) (clc.cc:906) ==439==by 0x40FD49: avnd_evt_clc_resp_evh(avnd_cb_tag*, avnd_evt_tag*) (clc.cc:414) ==439==by 0x42691E: avnd_evt_process (main.cc:626) ==439==by 0x42691E: avnd_main_process() (main.cc:577) ==439==by 0x4058F2: main (main.cc:202) ==439== --- 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.-- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
