#8 Double Removals

Errors
closed-accepted
9
2004-10-20
2004-10-04
Francesco Garosi
No

Double removals of entities are not prevented and cause
a segmentation fault. An example of this follows:

>>> c = clips.BuildClass('c', "(is-a USER)")
>>> c.Remove()
>>> c.Remove()

The first c.Remove() succeeds without complaint. Once
the second is executed, a segmentation fault happens
and the Python interpreter dies. It also happens in the
following circumstances:

>>> c = clips.BuildClass('c', "(is-a USER)")
>>> clips.SendCommand("(undefclass c)")
>>> c.Remove()

that is, when the entity had been deleted using a
standard CLIPS command. This happens because no
check is made for the entity pointer while attempting to
remove the entity itself.

Discussion

  • Logged In: YES
    user_id=328337

    The syndrome also affects generic inquiries to constructs
    that were removed from CLIPS namespace: as soon as they
    become "invalid", any property retrieval (eg. name, pretty-
    print form) which internally implies a function call, can lead to
    exactly the same problem. It does not happen always,
    however, and that is why the problem was not noticed before.

     
  • Logged In: YES
    user_id=328337

    I am testing now a new version of PyCLIPS where, each time
    a construct is accessed, the low-level access function also
    looks up for the construct to be still valid. This will of course
    affect performance in most interactions between Python and
    CLIPS; the performance degradation should be ininfluent in
    case of small amounts of constructs of each type.

    However, the creation of new constructs (eg. the
    Build<construct> functions) should not loose performance at
    all, and in no way the execution of rule systems within the
    CLIPS engine will be affected, as the CLIPS source code has
    not been modified. The performance loss will thus only be
    noticeable only when directly modifying constructs - which
    should be some kind of "static" entities - before and after
    CLIPS internal computations. Moreover, no change was made
    to functions that access facts and instances, so access to
    the "variable" parts of CLIPS programs will probably show
    ininfluent degradations.

     
  • Logged In: YES
    user_id=328337

    A version that does not have this problem has just been
    uploaded to CVS. The new version introduces an existence
    check before performing any operation that accesses every
    constructs data. On a machine of current generation, both
    the test suite and the application I'm writing do not show a
    real performance loss. However in both cases the number of
    constructs is limited: in case of a big amount of constructs
    and a consequently big amount of Python-CLIPS interaction
    the performance may suffer.

    In general, a look at the C code will show that every access
    to constructs will imply an O(n) sequence of comparisons for
    every construct, where n is the total number of constructs of
    the accessed type.

    The next release (1.0_05, will be out shortly) will be based on
    current CVS code and thus not affected by this bug.

     
  • Logged In: YES
    user_id=328337

    Current CVS and release 1.0_05 should fix the problem.

     
    • status: open --> closed-accepted