#35 Memory leaks


Many methods cause memory leak in the library. For instance the following calls slowly leaks:

clips.InitialFact().Slots.keys() # Leaks
clips.FactList() # Leaks
clips.RuleList() # Leaks

When running the attached example the memory leak is noticeable.


  • Santtu Jarvi

    Santtu Jarvi - 2009-04-26


  • Francesco Garosi

    • priority: 5 --> 6
  • Francesco Garosi

    • assigned_to: nobody --> franzg
  • Comment has been marked as spam. 

    You can see all pending comments posted by this user  here

    Anonymous - 2013-01-24


    I've done some poking around with Valgrind and I've found two things:

    1.) There was a trivial leak of list objects.
    2.) Facts were being leaked in two places.

    Using this memory_leak.py file attached to this bug I see a pretty dramatic improvement. At this point the extension module doesn't seem to have any significant leaks, although I think that the wrapper is leaking function and tuple objects.

    Unfortunately this patch makes several operations much, much slower, namely clips.Clear(), clips.Reset(), and clips.Run(). I haven't looked into why this is.

  • Francesco Garosi

    Do you also have some debugger output? You said you use valgrind, for instance.

    In order to look for specific leaks it could be useful for me to see if the leaks are in the CLIPS part or the wrapper (for instance: unreleased Python objects); I tried to automate most operations when it's about accessing lists of CLIPS objects (facts and rules for instance) from the wrapper, in order to avoid trivial errors. The operations you report didn't show leaks in the wrapper when I tested the list-retrieval routine in the wrapper, but as CLIPS is compiled along with the wrapper, maybe I can discover whether something happens in the CLIPS core.

    Thank you,


  • Caz

    Caz - 2014-03-18

    Has this been resolved? Thanks for replying!


Log in to post a comment.

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

Sign up for the SourceForge newsletter:

No, thanks