Re: [Sblim-devel] An issue related with sfcbd InvokeMethod and its root cause in cimXmlOps.y / cimXmlParserProcessed.c

[David H. <hel...@us...>]

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