Re: Garbage collection, part two...

From: Erick Gallesio <>
Date: Thu, 20 Apr 2000 23:16:37 +0200 (CEST)

Paul Anderson writes:
> Erick:
> I did a search of the code and found the following places
> that look suspicious. Note that we are still on 3.99.4.
> I found these by first identifying the types that allocate memory
> and then looking for places where the memory pointer is
> retrieved in a context where it the SCM value may be collected.
> I may have missed some other places.

Great Job! Thanks a lot for it.

> 1. In tcl-obj.c :: Tcl_GetStringFromObj, SCM value s is
> dropped, and will be collected, but CHARS(s) is returned
> and may be used elsewhere. My fix to this is to strdup
> CHARS(s) and return that. It is then the responsibility
> of the client to free it.

I don't like this solution, because this function is used a lot by Tk
(and a lot more by recent versions, and it will be too easy to forget
the deallocation. Another possibility would be to not provide the
function Tcl_GetStringFromObj and return a SCM instead of a char*
I have not applied this idea yet and will look for it tomorrow.

> 2. In port.c :: STk_load_file there is an occurrence of
> fname = CHARS(STk_internal_expand_file_name(fname)).
> I fixed this by turning it into
> sFname = STk_internal_expand_file_name(fname);
> fname = CHARS(sFname);
> where sFname is declared as a volatile.

OK! Patch applied.

> 3. A similar problem exists in port.c :: STk_error with
> Err(CHARS(internal_format(l, len, TRUE)));
> I fixed this by introducing a volatile SCM str and having:
> str = internal_format(l, len, TRUE);
> Err(CHARS(str), NIL);

Ok too.

> 4. In unix.c :: STk_resolve_link the SCM value p
> could be collected as it is not used after it is
> created except for the one occurrence of CHARS(p).
> This can be fixed by making the declaration a volatile.


> 5. In stklos.c :: STk_compute_applicable_methods there is
> a assignment:
> tmp = STk_makevect(len, NULL);
> followed by a "p = VECT(tmp)". As tmp is not subsequently used,
> then it is a candidate for collection, so p could be invalidated.
> The fix here is to make tmp a volatile.

Corrected too.

> Hope this helps.

Of course it does. Thanks again

                -- Erick
Received on Thu Apr 20 2000 - 23:19:57 CEST

This archive was generated by hypermail 2.3.0 : Mon Jul 21 2014 - 19:38:59 CEST