|
From: David H. <hel...@us...> - 2013-10-11 23:13:18
|
Hi Ting,
I think you are right, the type should not be set to -1 there. There is
no other place in the code where we do this; in all other places where the
type is not applicable or indeterminate, we set type = 0. That was
probably the intent here.
I did a quick test with similar XML and the SFCB TestMethodProvider. I
modified the callmethod1.xml file in ./test/TestProviders/test/,
eliminating the VALUE, and turning the PARAMVALUE into a self-closing tag
as you have. And it did hit the same parser code, and set the type as you
described. However in my test, the flow never hit the freeParamValue()
code, since the call to that comes from freeParamValues(), and in this
case there are no "xtokParamValues" to free. That's because nothing gets
added in buildInvokeMethodRequest(), because p->value.value would be null
after parsing this XML. So CMAddArg() never gets called.
The freeParamValue() DOES get called when I actually pass a param there,
such as the case of the unmodified callmethod1.xml file.
So I question whether freeParamValue() really got called in the case of
the XML you pasted above. More likely, the problem is just that SFCB
passed this bad type value to your provider, and your provider was unable
to handle it.
I will go ahead and fix this bug. Can you confirm that changing to
$$.type=0 does indeed fix your problem?
One caveat: this bug is preventing the code from entering the
updateMethodParamTypes() function in buildInvokeMethodRequest(). Once I
make the change it will enter that function, which attempts to determine
the correct CMPIType by checking how it is defined in the class repository
(i.e. how it is defined in the .mof file when it was compiled). In this
case it should start picking up the correct CMPIType for this parameter
(which I assume is "reference", as it is in your XML) and it will pass
THAT type to your provider, instead of the bad value it is passing now. At
that point your provider will have to handle the empty PARAMVALUE, which I
assume it is prepared to do, or you may have a different problem.
Just for curiosity, is there a reason you are passing an empty PARAMVALUE
here instead of no PARAMVALUE at all? Or is this just the XML that was
generated by your client code when it had no param to pass?
Thanks for bringing this forward.
-Dave H
David E. Heller
IBM Linux Technology Center
hel...@us...
Ting Wang <wan...@gm...>
10/09/2013 04:34 AM
To
sbl...@li...,
cc
Subject
[Sblim-devel] An issue related with sfcbd InvokeMethod and its root cause
in cimXmlOps.y / cimXmlParserProcessed.c
Hello,
We found conformance related problem in CIM-XML processing, could someone
look at the problem and help me conform? Thank you.
Problem description:
We found that following CIM-XML message does not get any response from
provider, although log shows that the method get invoked successfully.
"""
POST /cimom HTTP/1.1
Connection: Keep-Alive
Content-Type: text/xml;charset=UTF-8
Date: Wed, 09 Oct 2013 06:08:51 GMT
Authorization: Basic cm9vdDoxMjM0NTY3ODkw
Content-Length: 591
CIMObject:
root%2Fxyzsd%3AXYZ_VRAID_StoragePool.InstanceID%3D%22primordial_afdasd%3AVRAID_vmhba1%22
Accept-Language: *
Host: ?.???.??.???:5988
User-Agent: WBEM Solutions WBEM Java API3.1.2 07/16/2009 10:59
CIMOperation: MethodCall
CIMProtocolVersion: 1.0
CIMMethod: GetAvailableExtents
Accept: text/xml, application/xml
<?xml version="1.0" encoding="UTF-8"?><CIM CIMVERSION="2.0"
DTDVERSION="2.0"><MESSAGE ID="2013:9:9:2:1:8:51:15"
PROTOCOLVERSION="1.0"><SIMPLEREQ><METHODCALL
NAME="GetAvailableExtents"><LOCALINSTANCEPATH><LOCALNAMESPACEPATH><NAMESPACE
NAME="root"/><NAMESPACE NAME="xyzsd"/></LOCALNAMESPACEPATH><INSTANCENAME
CLASSNAME="XYZ_VRAID_StoragePool"><KEYBINDING NAME="InstanceID"><KEYVALUE
TYPE="string"
VALUETYPE="string">primordial_afdasd:VRAID_vmhba1</KEYVALUE></KEYBINDING></INSTANCENAME></LOCALINSTANCEPATH><PARAMVALUE
NAME="Goal"
PARAMTYPE="reference"/></METHODCALL></SIMPLEREQ></MESSAGE></CIM>
"""
Through debugging, we identified that the following fields in the CIM-XML
message caused the problem:
<PARAMVALUE NAME="Goal" PARAMTYPE="reference"/>
After we remove this parameter from the CIM-XML message, CIM client can
get response from sfcbd.
Root cause:
After careful analysis, we found the problem is caused by incorrect
handling in cimXmlOps.y:
paramValue
: XTOK_PARAMVALUE ZTOK_PARAMVALUE
{
$$.value.value=NULL;
$$.type=-1; // In case the paramValue is blank, type is assigned to
0xFFFFFFFF
}
However in cimXmlParserProcessed.c, the processing depends on "type". If
we previously hit the blank paramValue, then type will be 0xFFFFFFFF, and
it will match the first check, drop into freeRefArray() logic. As a
result, the logic will hit sanity check in free(), no response is sent
back due to this error.
static void freeParamValue(XtokParamValue *op)
{
if ((op->type & CMPI_refA) == CMPI_refA) {
freeRefArray(&op->valueRefArray);
} else if (op->type & CMPI_ARRAY) {
freeArray(&op->valueArray);
} else if ((op->type & CMPI_ref) == CMPI_ref) {
freeReference(&op->valueRef);
} else if ((op->type & CMPI_instance) == CMPI_instance
|| (op->type & CMPI_class) == CMPI_class) {
freeValue(&op->value);
}
}
Regards,
Ting
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
Sblim-devel mailing list
Sbl...@li...
https://lists.sourceforge.net/lists/listinfo/sblim-devel
|