Menu

#2745 enumerateClassNames + release(enum) crashes when using the XML backend

Stability
open
None
sfcc
5
2015-05-27
2015-03-27
No

enumerateClassNames crashes when using the XML backend.

Attached testcase. If you uncomment either the release() for the enumeration or the array, it tries to release a object path that produces the crash.
If you change enumerateClassNames to enumerateClasses, it works, as long you release the enumeration or the array and not both (both are the same data).

I can reproduce the crash with the examples shipped: v2test_ecn.c

result: CIM_AbstractComponent
result: CIM_Indication
result: CIM_ManagedElement
result: CIM_Dependency
result: CIM_ServiceAffectsElement
==25984== Invalid read of size 8
==25984==    at 0x5E05FB0: native_release_CMPIValue (value.c:90)
==25984==    by 0x5E0074A: __aft_release (array.c:97)
==25984==    by 0x5E01311: __eft_release (enumeration.c:59)

The crash does not happen with the SfbLocal connection, as
native_release_CMPIValue is not implemented in this case.

 Testing enumerateClassNames
 using SfcbLocal interface : host = localhost userid = root
 calling enumClassNames
 back from  enumClassNames
results:
result: root/cimv2:CIM_AbstractElementStatisticalData
result: root/cimv2:CIM_AbstractComponent
result: root/cimv2:CIM_Indication
result: root/cimv2:CIM_ManagedElement
result: root/cimv2:CIM_Dependency
result: root/cimv2:CIM_ServiceAffectsElement
```
2 Attachments

Discussion

  • Dave Heller

    Dave Heller - 2015-05-27
    • assigned_to: Dave Heller
     
  • Dave Heller

    Dave Heller - 2015-05-27

    Hi Duncan,

    I'm not seeing any such crash using your program or any of the sample programs, The exception is when I try to free both the enum and the array, which is wrong as you pointed out; then it will crash. Other than that I can uncomment all the free()s in your test program without seeing any problem. So I am wondering if you can give me a little more info about where you are seeing the crash: what distro and arch, what kernel level, what level of glibc.

    Also can you be a bit more specific about which free is causing the crash? Is it the free of one of the objects like op or enm, or is it the free of the client or CIMCEnv?

    Really, there shouldn't be any difference in the object release() calls between XML and SfcbLocal interfaces. All the object functions calls should behave in the same way for both. Not sure what you mean by "native_release_CMPIValue is not implemented" in the case of SfcbLocal. You are referring to some call made from within the parser, which you think is related to the crash? (native_release_CMPIValue() is called several places in the parser additionally)

    WRT to release of the CIMCEnv, in both cases we dlopen() a client library; in the case if XML it's SFCC's native library and in the case of SfcbLocal it's a library provided by SFCB. It's odd that you're seeing a problem with the XML interface, in the cases where we do see an error like this it's usually on the local interface. Rather than calling free() here you can instead call ReleaseCIMCEnv() which will additionally dlcose() the library, although usually it doesn't matter when the program's about to exit anyway. But maybe that is somehow related to your crash.

    It looks like your output was generated by valgrind? Perhaps you were using that to analyze your crash? Can you produce this w/o valgirind, and generate a core, and a stack trace from gdb?

     
  • Dave Heller

    Dave Heller - 2015-05-27

    Possibly you are seeing something related to [bugs:#2730]. There was a regression from my patch there, which caused a crash. So please make sure you are using SFCC v2.2.8 or later (or v2.2.6 or earlier).

     

    Related

    Bugs: #2730


Log in to post a comment.

MongoDB Logo MongoDB