Yes, you are correct. Only the release() in the VALUENAMEDINSTANCE block is needed; this is sufficient to stop the originally reported leak; the others should be removed. We don't need to / don't want to release any value passed to simpleArrayAdd(), as this is part of the response that will be returned to the client.
I think, what happened here: I found the missing free in the VALUENAMEDINSTANCE block pretty quickly, and in my haste assumed the other blocks needed the same, not seeing that the logic is different there, and the op becomes part of the response in those cases, and should not be freed.
Thanks again, Klaus!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Commit [1152bb] for SFCC 2.2.7
Related
Commit: [1152bb]
Hmm, this is crashing Openwsman when doing 'enumerate class names' via the XML interface.
Looking further:
backend/cimxml/grammar.c:446 calls simpleArrayAdd, passing the object path as a CMPIValue pointer
simpleArrayAdd() in backend/cimxml/array.c:274 calls setElementAt with an 'opt' value of 1
this makes setElementAt (array.c:202) copy the value, while the normal behavior of setElementAt is to clone the value.
Patch: Don't release objectpath when used as value
Sorry for the delay, just looking at this now...
Yes, you are correct. Only the release() in the VALUENAMEDINSTANCE block is needed; this is sufficient to stop the originally reported leak; the others should be removed. We don't need to / don't want to release any value passed to simpleArrayAdd(), as this is part of the response that will be returned to the client.
I think, what happened here: I found the missing free in the VALUENAMEDINSTANCE block pretty quickly, and in my haste assumed the other blocks needed the same, not seeing that the logic is different there, and the op becomes part of the response in those cases, and should not be freed.
Thanks again, Klaus!