Making duplicate instances leaks memories

[yoshiaki]

Hello,
Batching duplicate.txt seems to be leaking memories
(My CLIPS has some modification in order to detect memory-leaks more easily).

$ ./clips -f duplicate.txt
CLIPS (6.4.2 5/7/24)
CLIPS> (defclass Base (is-a USER)
(role abstract)
)
CLIPS>
(defclass Derived (is-a Base)
(role concrete)
(slot text)
)
CLIPS>
(make-instance [derived] of Derived)
[derived]
CLIPS> (defrule test =>)
CLIPS> (make-instance [derived] of Derived)
[derived]
CLIPS> (exit)
CLIPS>
[ENVRNMNT8] Environment data not fully deallocated.

[ENVRNMNT8] MemoryAmount = 32.

[ENVRNMNT8] MemoryCalls = 2.

Here is the Valgrind's output of my CLIPS.

==4460== HEAP SUMMARY:
==4460==     in use at exit: 32 bytes in 2 blocks
==4460==   total heap usage: 3,162 allocs, 3,160 frees, 1,739,574 bytes allocated
==4460==
==4460== 32 (8 direct, 24 indirect) bytes in 1 blocks are definitely lost in loss record 2 of 2
==4460==    at 0x4C29BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==4460==    by 0x437CE2: genalloc (memalloc.c:118)
==4460==    by 0x438155: gm2 (memalloc.c:362)
==4460==    by 0x42BC61: BuildDefaultSlots (insmngr.c:928)
==4460==    by 0x42AC5D: BuildInstance (insmngr.c:424)
==4460==    by 0x42A4B9: MakeInstanceCommand (insmngr.c:241)
==4460==    by 0x42B88E: InactiveMakeInstance (insmngr.c:733)
==4460==    by 0x4055FD: EvaluateExpression (evaluatn.c:213)
==4460==    by 0x40342B: RouteCommand (commline.c:1051)
==4460==    by 0x402DC1: ExecuteIfCommandComplete (commline.c:820)
==4460==    by 0x402A9D: CommandLoop (commline.c:700)
==4460==    by 0x401B66: main (main.c:84)
==4460==
==4460== LEAK SUMMARY:
==4460==    definitely lost: 8 bytes in 1 blocks
==4460==    indirectly lost: 24 bytes in 1 blocks
==4460==      possibly lost: 0 bytes in 0 blocks
==4460==    still reachable: 0 bytes in 0 blocks
==4460==         suppressed: 0 bytes in 0 blocks
==4460==
==4460== For counts of detected and suppressed errors, rerun with: -v
==4460== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

The patch attached is one solution for it.
Thanks.

[CLIPS Support]

I checked in a fix for this to the sourceforge repository (https://sourceforge.net/p/clipsrules/code/HEAD/tree/). I handled the issue differently than your attached patch. Deletion of instances can be deferred if the object system thinks they may be matched by a rule, but in this case the instance is of a non-reactive class, so since it cannot be matched by a rule, it's safe to delete it immediately rather than defer deletion.

[yoshiaki]

It looks fine.

Thanks.

2024年6月18日火曜日 8:23:22 UTC+9 CLIPS Support: