Nasty bug in current PyCLIPS

I have discovered a significantly nasty bug in current PyCLIPS implementation, and since the bug is in the low-level submodule, it can lead to unexpected segmentation faults. It takes place when the code using PyCLIPS tries to remove an entity twice: please read

http://sourceforge.net/tracker/index.php?func=detail&aid=1039974&group_id=114052&atid=667038

for an example.

The bug appears when an entity is removed for the second time using the shadow-class method Remove(): current CLIPS implementation assumes that if you directly remove a construct from the system, the construct has to actually be present in it, thus calling the associated removal function without checking. Since the first destruction of an entity can take place both via Remove() and via a command directly sent to the engine (using Eval(), SendCommand() or even Run() if it implies any undef<construct> command), preventing such a situation without scanning the entire construct list is quite difficult. The current idea is to perform such a scan every time the user tries to delete a construct: this could make construct deletion significantly slower in case there is a large amount of these.

Only constructs however are affected: facts and instances use a different method for their destruction, so the bug does not apply to Retract() and Instance.Remove(). For these two types of entity, in case of a double removal an exception arises stating that the garbage collection phase has entered. Probably the text associated with this exceptions will be changed to something less confusing, though.

Please use the Remove() method carefully in your programs, until the bug is closed, and monitor the bug itself if you are using PyCLIPS in an application. I'm sorry for the inconvenience, and every suggestion will be appreciated.

Posted by Francesco Garosi 2004-10-05

Log in to post a comment.

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

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks