#2730 More memory leaks in backend/cimxml/grammer.c

Memory_Leak
closed-fixed
None
sfcc
5
2014-07-02
2014-03-25
Dave Heller
No

More memory leaks in backend CIM-XML parser, similar to tracker 3547832 / [bugs:#2503].

This is LTC 107502

Related

Bugs: #2503
Bugs: #2745
News: 2014/11/new-release-sfcc-228

Discussion

  • Dave Heller

    Dave Heller - 2014-03-26

    Commit [1152bb] for SFCC 2.2.7

     

    Related

    Commit: [1152bb]

  • Dave Heller

    Dave Heller - 2014-03-26
    • status: open --> pending-fixed
     
  • Dave Heller

    Dave Heller - 2014-03-28
    • Status: pending-fixed --> closed-fixed
     
  • Klaus Kämpf

    Klaus Kämpf - 2014-06-20

    Hmm, this is crashing Openwsman when doing 'enumerate class names' via the XML interface.

     
    • Klaus Kämpf

      Klaus Kämpf - 2014-06-20

      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.

       
  • Dave Heller

    Dave Heller - 2014-07-02

    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!

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks