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.
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.
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.
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);
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.
Hope this helps. As always, if you have questions, please feel
free to ask.
Paul.
______
Paul Anderson. GrammaTech, Inc. Tel: +1 607 273-7340
mailto:paul_at_grammatech.com
http://www.grammatech.com
Received on Mon Apr 17 2000 - 17:53:23 CEST