Hi Anders, Praveen,
sizeof(SaNameT) is not the right size to request the memory allocation any
more. It should be the real size (length of string + 2 bytes of .length). It
will looks like this
saNtfPtrValAllocate(notHandle, strlen(saAisNameBorrow(&name)) + 2,
(vo
Hi Anders,
I have missed this test case. I'm pretty sure it's a leak in server side
Thanks,
Minh
On 7/30/2014 10:20 PM, Anders Widell wrote:
> See my comments inline.
>
> / Anders W
>
> On 07/23/2014 06:55 AM, minhchau wrote:
>> Hi Anders W,
>>
>> Please see comments inline
>>
>> Thanks,
>> Minh
Hi Nagu,
regarding item 1 I have to check with HansF. Item 2, if
saAmfCompCSISetCallbackTimeout is not configured then saAmfCtDefCallbackTimeout
is used.
This patch introduces changing attributes in SaAmfCompType and if someone wants
to change saAmfCtDefCallbackTimeout it will affect
saAmfCom
saAisNameLend() adds a terminating NUL character, so I think you would
still need strlen(saAisNameBorrow(&name)) + 2 + 1 even with Praveen's
patch, otherwise saAisNameLend() will write one byte past the end of the
allocated buffer when the string is shorter than 256 bytes. Another
concern is, c
osaf/services/saf/amf/amfd/compcstype.cc | 13 ++---
osaf/services/saf/amf/amfd/imm.cc| 3 ++-
osaf/services/saf/amf/amfd/include/imm.h | 2 +-
osaf/services/saf/amf/amfd/su.cc | 18 --
4 files changed, 25 insertions(+), 11 deletions(-)
As of now, if
Summary: amfd: return FAILED_OP to RtAttrUpdateCallbackT if RtObjectUpdate_2
fails [#426]
Review request for Trac Ticket(s): #426
Peer Reviewer(s): Anders Bj, Hans F, Hans N, Praveen
Pull request to:
Affected branch(es): All
Development branch: Default
Impacted
On 31-Jul-14 1:39 PM, Anders Widell wrote:
> saAisNameLend() adds a terminating NUL character, so I think you would
> still need strlen(saAisNameBorrow(&name)) + 2 + 1 even with Praveen's
> patch, otherwise saAisNameLend() will write one byte past the end of
> the allocated buffer when the stri
After looking a bit more into the code, I see that this is quite tricky.
:-) SaNtfValueT is used in many situations, not just for additional
info. The solution should handle all cases where SaNtfValueT in the same
way.
One possibility could be that encodeSaNtfValueT() keeps track of all
SaName
On 07/31/2014 11:10 AM, praveen malviya wrote:
>
> On 31-Jul-14 1:39 PM, Anders Widell wrote:
>> saAisNameLend() adds a terminating NUL character, so I think you
>> would still need strlen(saAisNameBorrow(&name)) + 2 + 1 even with
>> Praveen's patch, otherwise saAisNameLend() will write one byte
On 31-Jul-14 2:50 PM, Anders Widell wrote:
>
> On 07/31/2014 11:10 AM, praveen malviya wrote:
>>
>> On 31-Jul-14 1:39 PM, Anders Widell wrote:
>>> saAisNameLend() adds a terminating NUL character, so I think you
>>> would still need strlen(saAisNameBorrow(&name)) + 2 + 1 even with
>>> Praveen's
I am leaning towards your suggested solution for SA_NTF_VALUE_LDAP_NAME
now. :-) It will be the easiest one to implement in NTF, but it may be a
bit non-obvious to the user. We have to clearly document that for
SA_NTF_VALUE_LDAP_NAME, the user must allocate strlen(x) + 3 bytes.
With the help of
Note that the usage of SA_NTF_VALUE_LDAP_NAME for SaNtfValueT is not
consistent.Currentlythentfimcn_notifier.c,function
fill_attribute_value(), treat SA_NTF_VALUE_LDAP_NAME as SA_NTF_VALUE_STRING,
it drop out 2 bytes of .length.
. So it's not always "strlen(x)
Yes I noticed, but that is a bug in ntfimcn_notifier.c, isn't it? The
SAF spec says that for SA_NTF_VALUE_LDAP_NAME, the data type is SaNameT.
/ Anders Widell
On 07/31/2014 12:45 PM, minhchau wrote:
> Note that the usage of SA_NTF_VALUE_LDAP_NAME for SaNtfValueT is not
> consistent. Currently t
On 31-Jul-14 3:47 PM, Anders Widell wrote:
> I am leaning towards your suggested solution for
> SA_NTF_VALUE_LDAP_NAME now. :-) It will be the easiest one to
> implement in NTF, but it may be a bit non-obvious to the user. We have
> to clearly document that for SA_NTF_VALUE_LDAP_NAME, the user
Yes it's a bug I think so, but I'm not sure if we can fix it due to backward
compatibility.
On 7/31/2014 8:49 PM, Anders Widell wrote:
Yes I noticed, but that is a bug in ntfimcn_notifier.c, isn't it? The SAF
spec says that for SA_NTF_VALUE_LDAP_NAME, the data type is SaNameT.
/
On 07/31/2014 01:40 PM, praveen malviya wrote:
>
> On 31-Jul-14 3:47 PM, Anders Widell wrote:
>> I am leaning towards your suggested solution for
>> SA_NTF_VALUE_LDAP_NAME now. :-) It will be the easiest one to
>> implement in NTF, but it may be a bit non-obvious to the user. We
>> have to clea
You have a point, backwards compatibility is tricky when fixing bugs. So
the current situation is then that sometimes SA_NTF_VALUE_LDAP_NAME
comes with two bytes of length information in the beginning, and
sometimes it doesn't. How will the user know how to interpret the value?
I don't see a pr
On 31-Jul-14 5:31 PM, Anders Widell wrote:
>
> On 07/31/2014 01:40 PM, praveen malviya wrote:
>>
>> On 31-Jul-14 3:47 PM, Anders Widell wrote:
>>> I am leaning towards your suggested solution for
>>> SA_NTF_VALUE_LDAP_NAME now. :-) It will be the easiest one to
>>> implement in NTF, but it may b
On 31-Jul-14 5:36 PM, Anders Widell wrote:
> You have a point, backwards compatibility is tricky when fixing bugs.
> So the current situation is then that sometimes SA_NTF_VALUE_LDAP_NAME
> comes with two bytes of length information in the beginning, and
> sometimes it doesn't. How will the use
Summary: amfd: allow lock on su after issue of shutdown [#582]
Review request for Trac Ticket(s): #582
Peer Reviewer(s): Hans F, Hans N, Praveen
Pull request to: <>
Affected branch(es): All.
Development branch: Default
Impacted area Impact y/n
osaf/services/saf/amf/amfd/sg_2n_fsm.cc | 14 +++---
osaf/services/saf/amf/amfd/su.cc| 18 ++
2 files changed, 21 insertions(+), 11 deletions(-)
Shutdown operation was rejected because shitdown operation
was going on. Amf should respect lock operation as per Spe
osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc | 30 +++--
1 files changed, 10 insertions(+), 20 deletions(-)
For a rolling upgrade procedures with the following prerequisites:
-Target node template containing SU type
-The SU type is hosting several components
the step calc
Summary: smfd: correctly calculate steps for SU template
Review request for Trac Ticket(s): 971
Peer Reviewer(s): Mathi
Pull request to:
Affected branch(es): 4.4, default
Development branch: default
Impacted area Impact y/n
osaf/services/saf/amf/amfd/include/amfd.h |1 +
osaf/services/saf/amf/amfd/include/sg.h |8 ++
osaf/services/saf/amf/amfd/ndproc.cc | 20 +
osaf/services/saf/amf/amfd/sg.cc | 114 +-
osaf/services/saf/amf/amfd/sg_nway_fsm.cc |2 +-
5 f
Summary: amfd : reply for admin operation on SG after its completion [#293]
Review request for Trac Ticket(s): #293
Peer Reviewer(s): AMF contributors
Pull request to: <>
Affected branch(es): ALL
Development branch: <>
Impacted area Impact y/n
25 matches
Mail list logo
