Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#33 Obscure crash in testsuite for svn296 on Win32

Errors
closed
9
2008-02-22
2008-02-05
Francesco Garosi
No

The code in SVN (SF.net revision 296, build 338) causes a crash on Windows just after execution of test_fact.py/ctf_Template_10. At the moment the reason is difficult to explain, as it takes place in CLIPS code where a pointer to the next element in a list traversal function becomes (void *)0x00000001 instead of anything valid.

The PyCLIPS function causing the error is e_clear() at the low-level, Clear() in the high-level module.

Discussion

    • labels: --> Low Level (C) Errors
    • milestone: --> Errors
    • priority: 5 --> 9
    • assigned_to: nobody --> franzg
     
  • Bug Explanation

     
    Attachments
  • Logged In: YES
    user_id=328337
    Originator: YES

    The attached Python file reproduces the bug without having to run the entire test suite...
    File Added: bug_1886693.py

     
  • Logged In: YES
    user_id=328337
    Originator: YES

    Since Fact object pointers were not removed from the hash map upon Fact deallocation, when Python Fact object were destroyed (del, garbage collection) pointers to non-existing objects could remain in the said map, and when the function that declares a fact as "lost" was called, it could set a TRUE (0x00000001) value somewhere - almost randomly. Now CLIPS environments are configured to carry the information about hash map with themselves, and Fact objects unregister themselves from the map when deleted, removing the inconsistency. The fix will be posted to SVN ASAP, and the bug will be closed then.

     
  • Logged In: YES
    user_id=328337
    Originator: YES

    The fixes for this bug or request have been accepted and
    committed to current RCS tree: next release will include these
    fixes, possibly among other enhancements.

     
  • Logged In: YES
    user_id=328337
    Originator: YES

    svn297 implements changes that fix this bug and another one.

     
    • status: open --> closed