Re: Garbage collection, part two...

From: Erick Gallesio <eg_at_unice.fr>
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.

Yep.

> 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