Re: Re: [Lush-users] loosing memory in compiled code

On Tuesday 21 February 2006 02:28 pm, Ralf Juengling wrote:
> I don't believe that. ;-) Let's look at some code:
> 
> (defclass A Object
>    ((-idx2- (-double-)) m) )
> 
> (defmethod A A (n)
>    ((-int-) n)
>    (setq m (double-matrix n n) ))
> 
> (defmethod A do ()
>    (let ((mc (idx-copy m)))
>      (idx-transpose mc '(0 1))
>      (idx-copy mc m)
>      () ))
> 
> (defun iterate (m n)
>    ;; iterate m times with an nxn matrix
>    (let ((a (new A n)))
>      (for (i 1 m)
>           (==> a do))))
> 
> (dhc-make ()
>            (A A do)
>            )

I am checking this code, and I cannot see a memory leak.
I found and corrected three little unrelated memory leaks 
in the process, saving a total of 400 bytes.

> When I looked into lisp_c.c I found
>     delayed_kill_list = 0;

This variable only matters between lines 2711 and 2720 and things 
only get added to that list when update_lisp_from_c() runs.

> In method (A . do) a temporary copy mc of m gets created. This copy
> is not returned. The size of mc (of the data block the storage points
> to) is not known until runtime, so it need to be allocated dynamically.

And it gets deleted in wipe_out_temps() before returning from dh_listeval().

> The code in src/lisp_c.c distinguishes between dynamically 
> allocated objects that "belong to C" vs. objects that "belong to Lisp".
> Why this disinction--after all lisp_c is part of the interpreter?
> Looking at the example aboive, is there a difference in "ownership" of
> the instance variable m depending on whether the class constructor
> is compiled or not? How exactly is the memory for m handled in each
> case?

Object belong to C when they are manually allocated from C code, 
for instance using "dynamic.lsh". lisp_c tracks these objects
in order to be able to present their contents to the interpreter (although 
their memory allocation is entirely under the control of the C code.)
This is obviously not the case here.

Nothing "belongs to C" unless someone calls one of 
the cside_create_XXX() functions from the compiled code
(typically after malloc() or equivalent).

> When I stop the program and trigger an
> error in the interpreter shell, then lush releases that
> memory. So it looks like there are reference counting bugs
> somewhere.

That is a clear indicator of an overlock 
in the reference counting code.
You can use function (used) to see how many
lisp objects are in use at a given moment.

See "Finding locking bugs" in the obsolete documentation :-).



- L.







-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642