[tickets] [opensaf:tickets] #1743 osaf: Build fails with GCC version 6
- **status**: accepted --> review
---
** [tickets:#1743] osaf: Build fails with GCC version 6**
**Status:** review
**Milestone:** 5.0.RC1
**Created:** Fri Apr 08, 2016 12:34 PM UTC by Anders Widell
**Last Updated:** Fri Apr 08, 2016 12:34 PM UTC
**Owner:** Anders Widell
The following build errors were observed with GCC version 6 and optimization
level -O3:
imm_dumper.cc: In function 'int main(int, char**)':
imm_dumper.cc:149:5: error: this 'if' clause does not guard...
[-Werror=misleading-indentation]
if ((c = getopt_long(argc, argv, "hp:x:c:a:", long_options, NULL)) == -1)
^~
imm_dumper.cc:152:13: note: ...this statement, but the latter is misleadingly
indented as if it is guarded by the 'if'
switch (c) {
^~
compdb.cc: In function 'int comp_init(AVND_COMP*, const SaImmAttrValuesT_2**)':
compdb.cc:1579:2: error: this 'if' clause does not guard...
[-Werror=misleading-indentation]
if
(immutil_getAttr(const_cast("saAmfCompCSISetCallbackTimeout"),
attributes,
^~
compdb.cc:1582:3: note: ...this statement, but the latter is misleadingly
indented as if it is guarded by the 'if'
comp->use_comptype_attr->set(CsiSetCallbackTimeout);
^~~~
compdb.cc:1584:2: error: this 'if' clause does not guard...
[-Werror=misleading-indentation]
if
(immutil_getAttr(const_cast("saAmfCompCSIRmvCallbackTimeout"),
attributes,
^~
compdb.cc:1587:3: note: ...this statement, but the latter is misleadingly
indented as if it is guarded by the 'if'
comp->use_comptype_attr->set(CsiRemoveCallbackTimeout);
^~~~
tet_Log_recov.c:76:18: error: 'wr_delay' defined but not used
[-Werror=unused-const-variable=]
static const int wr_delay = 100*1000; /* 100 ms */
^~~~
test_saImmOmCcbObjectCreate_2.c:20:30: error: 'nonExistingClassName' defined
but not used [-Werror=unused-const-variable=]
static const SaImmClassNameT nonExistingClassName = (SaImmClassNameT) __FILE__;
^~~~
In file included from ../../../../../osaf/libs/core/include/ncs_osprm.h:32:0,
from ../../../../../osaf/libs/core/include/ncs_ubaid.h:45,
from ../../../../../osaf/libs/core/include/mbcsv_papi.h:29,
from lgs.h:30,
from lgs_stream.cc:29:
../../../../../osaf/libs/core/common/include/logtrace.h: In function 'int
log_stream_file_close(log_stream_t*)':
../../../../../osaf/libs/core/common/include/logtrace.h:131:46: error:
'errno_ret' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
#define LOG_NO(format, args...) _logtrace_log(__FILE__, __LINE__, LOG_NOTICE,
(format), ##args)
^
lgs_stream.cc:978:6: note: 'errno_ret' was declared here
int errno_ret;
^
---
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.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #1741 amf: allow increase of saAmfSGMaxStandbySIsperSU for N+M SG while UNLOCKED
- **status**: accepted --> review --- ** [tickets:#1741] amf: allow increase of saAmfSGMaxStandbySIsperSU for N+M SG while UNLOCKED** **Status:** review **Milestone:** 4.7.1 **Created:** Thu Apr 07, 2016 02:13 PM UTC by Alex Jones **Last Updated:** Thu Apr 07, 2016 02:13 PM UTC **Owner:** Alex Jones In order to support in-service capacity additionfor N+M models (you want to go from 2+1 to 3+1 in-service), we need to allow saAmfSGMaxStandbySIsperSU to be increased dynamically. This is very similar to ticket 871. --- 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.-- ___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #1734 amf: handing of CSI dependencies should be same for standby as active
- **status**: accepted --> review --- ** [tickets:#1734] amf: handing of CSI dependencies should be same for standby as active** **Status:** review **Milestone:** 4.7.1 **Created:** Wed Apr 06, 2016 06:32 PM UTC by Alex Jones **Last Updated:** Wed Apr 06, 2016 06:32 PM UTC **Owner:** Alex Jones saAmfCSIDependencies should follow the same order for STANDBY as ACTIVE. Even though this is not explicitly mentioned in AMF B.04.01, we agreed that it should be the case. >From "users" mailing list: Hi Alex/Praveen, I don't remember being part of a discussion where the STANDBY assignments should be given the same treatment as 'QUIESCED/QUIESCING' in this scenario. I guess the implementation just took that route based on the words "or another HA state" as-in P 186, section 3.8.1.3, lines29- 30 - "the active HA state is removed from components or another HA state is assigned to components" In my opinion, I think both ACTIVE and STANDBY assignments should follow the same ordering of dependencies . I also think this brings no additional considerations whether it is PI or NPI. Cheers, Mathi. --- 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.-- ___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #1743 osaf: Build fails with GCC version 6
---
** [tickets:#1743] osaf: Build fails with GCC version 6**
**Status:** accepted
**Milestone:** 5.0.RC1
**Created:** Fri Apr 08, 2016 12:34 PM UTC by Anders Widell
**Last Updated:** Fri Apr 08, 2016 12:34 PM UTC
**Owner:** Anders Widell
The following build errors were observed with GCC version 6 and optimization
level -O3:
imm_dumper.cc: In function 'int main(int, char**)':
imm_dumper.cc:149:5: error: this 'if' clause does not guard...
[-Werror=misleading-indentation]
if ((c = getopt_long(argc, argv, "hp:x:c:a:", long_options, NULL)) == -1)
^~
imm_dumper.cc:152:13: note: ...this statement, but the latter is misleadingly
indented as if it is guarded by the 'if'
switch (c) {
^~
compdb.cc: In function 'int comp_init(AVND_COMP*, const SaImmAttrValuesT_2**)':
compdb.cc:1579:2: error: this 'if' clause does not guard...
[-Werror=misleading-indentation]
if
(immutil_getAttr(const_cast("saAmfCompCSISetCallbackTimeout"),
attributes,
^~
compdb.cc:1582:3: note: ...this statement, but the latter is misleadingly
indented as if it is guarded by the 'if'
comp->use_comptype_attr->set(CsiSetCallbackTimeout);
^~~~
compdb.cc:1584:2: error: this 'if' clause does not guard...
[-Werror=misleading-indentation]
if
(immutil_getAttr(const_cast("saAmfCompCSIRmvCallbackTimeout"),
attributes,
^~
compdb.cc:1587:3: note: ...this statement, but the latter is misleadingly
indented as if it is guarded by the 'if'
comp->use_comptype_attr->set(CsiRemoveCallbackTimeout);
^~~~
tet_Log_recov.c:76:18: error: 'wr_delay' defined but not used
[-Werror=unused-const-variable=]
static const int wr_delay = 100*1000; /* 100 ms */
^~~~
test_saImmOmCcbObjectCreate_2.c:20:30: error: 'nonExistingClassName' defined
but not used [-Werror=unused-const-variable=]
static const SaImmClassNameT nonExistingClassName = (SaImmClassNameT) __FILE__;
^~~~
In file included from ../../../../../osaf/libs/core/include/ncs_osprm.h:32:0,
from ../../../../../osaf/libs/core/include/ncs_ubaid.h:45,
from ../../../../../osaf/libs/core/include/mbcsv_papi.h:29,
from lgs.h:30,
from lgs_stream.cc:29:
../../../../../osaf/libs/core/common/include/logtrace.h: In function 'int
log_stream_file_close(log_stream_t*)':
../../../../../osaf/libs/core/common/include/logtrace.h:131:46: error:
'errno_ret' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
#define LOG_NO(format, args...) _logtrace_log(__FILE__, __LINE__, LOG_NOTICE,
(format), ##args)
^
lgs_stream.cc:978:6: note: 'errno_ret' was declared here
int errno_ret;
^
---
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.--
___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #1739 Logsv is providing same active handle value for different api calls
The above sequence was done in one process or in two? 1) On one process This could be an strange point! The question should come to Handle Mananger (`ncshm_create_hdl`), out of logsv scope, how it comes to have one handle ID for 2 times calling to `ncshm_create_hdl`. If this is the case, I will re-check the code and ask person in charge of handle manager. 2) On two processes I tried but not be able to reproduce the same phenomenon as yours. Can you help to collect the Agent/service trace log? --- ** [tickets:#1739] Logsv is providing same active handle value for different api calls** **Status:** unassigned **Milestone:** 4.6.2 **Created:** Thu Apr 07, 2016 11:48 AM UTC by Ritu Raj **Last Updated:** Thu Apr 07, 2016 11:48 AM UTC **Owner:** nobody Setup: Changeset- 7436 Version - opensaf 5.0 Issue : Logsv is issuing same active handle value for different api calls Steps: -> The logsv application stores the global system stream handle and for couple of scenarios , initialization and finalization has been done. -> At the startup of the application, system stream handle (4288675841) is obtained. -> After couple of flows, the initialization api saLogInitialize() obtained same handle ( 4288675841) and was finalized. -> So when saLogWriteLogAsync() api is invoked with the earlier obtained system stream handle, it is returning SA_AIS_ERR_BAD_HANDLE. Note that the init handle associated with the system stream handle 4288675841 is not finalized. 100|0|Invoking saLogInitialize() 100|0| Return value : <-- SA_AIS_OK 100|0| Handle obtained is 4290772993 100|0|Invoking saLogStreamOpen_2() 100|0|Handle used is 4290772993 100|0| Return value : <-- SA_AIS_OK 100|0| Handle obtained is 4288675841 100|0|Invoking saLogStreamOpen_2() 100|0|Handle used is 4290772993 100|0| Return value : <-- SA_AIS_OK 100|0| Handle obtained is 4287627265 100|0|Invoking saLogStreamOpen_2() 100|0|Handle used is 4290772993 100|0| Return value : <-- SA_AIS_OK 100|0| Handle obtained is 4286578689 100|0|system stream handle 4288675841 ... 100|0|Invoking saLogInitialize() 100|0| Return value : <-- SA_AIS_OK 100|0| Handle obtained is 4288675841 100|0|Invoking saLogFinalize() 100|0| Handle used is 4288675841 100|0| Return value : <-- SA_AIS_OK 100|0|Invoking saLogSelectionObjectGet() 100|0| Return value : <-- SA_AIS_ERR_BAD_HANDLE 100|0|Invoking saLogWriteLogAsync() 100|0|Handle used is 4288675841 100|0| Return value : <-- SA_AIS_ERR_BAD_HANDLE 100|0|saLogWriteLogAsync return values did not match Actual_Value :9 Expected_Value :1 This application used to work with 4.7 --- 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.-- ___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
