Memory leak in scm_c_eval_string?

Memory leak in scm_c_eval_string?

[Michael J. Barillier]

I'd appreciate someone confirming that scm_c_eval_string doesn't leak
memory.  From strports.c:

  ,----
  | SCM
  | scm_c_eval_string (const char *expr)
  | {
  |   return scm_eval_string (scm_makfrom0str (expr));
  | }
  `----

(NB: This is from guile-1.6.7 - the CVS version has scm_makfrom0str
deprecated/discouraged.)

My concern is the cell returned from scm_makfrom0str, which would be
stack-resident as a temporary value.  Scm_makfrom0str does a malloc to
allocate memory for expr, so if I was to do something like:

  scm_c_eval_string("(display \"foo\")");
  scm_c_eval_string("(display \"bar\")");

the stack frame created for the first call to scm_c_eval_string would be
overlaid on the second invocation, and the temporary cell created in the
first call overwritten so that the pointer from the first malloc is
lost and the memory allocated to hold "(display \"foo\")" leaked.

Am I needlessly worrying about this?

Additionally, within a Guile extension how can I handle cells returned
from library functions that are effectively thrown away?  e.g.:

  SCM_DEFINE( example, "example", 0, 0, 0, (), "Example." )
  #define FUNC_NAME s_example
  {
      SCM tmp;
      int n;
      tmp = scm_c_eval_string("(list \"foo\" \"bar\" \"baz\")");
      n = do_something_with_tmp(tmp);
      return SCM_MAKINUM(n);
  }
  #undef FUNC_NAME

Will the list returned from scm_c_eval_string be garbage-collected, or
leaked?

thx -

-- 
Michael J. Barillier   ///   http://www.blackwolfinfosys.net/~blackwolf/
.O.  |  ``Experience with many protocols has shown that protocols with
..O  |  few options tend towards ubiquity, whereas protocols with many
OOO  |  options tend towards obscurity.''  -- RFC 2821


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Memory leak in scm_c_eval_string?

[Kevin Ryde]

"Michael J. Barillier" <blackwolf@blackwolfinfosys.net> writes:
>
> Am I needlessly worrying about this?

Yep.  When there are no more pointers to an object, it's reaped.

> Will the list returned from scm_c_eval_string be garbage-collected,

Yep.

(I'd thought a couple of times it'd be nice to be able to explicitly
gc an object, when you know for sure it's now inaccessible.  Could get
into a lot of trouble if it wasn't, but for temporary values in low
level functions it might hold off a gc for a little longer.)


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Memory leak in scm_c_eval_string?

[Michael J. Barillier]

>>>>> "kr" == Kevin Ryde <user42@zip.com.au> writes:

    >>  Am I needlessly worrying about this?

    kr> Yep.  When there are no more pointers to an object, it's reaped.

D'oh - forgive the mental lapse.  GC reaps objects no longer pointed
*to* - I knew that.  The other bit I was missing was that the library
functions returning an SCM return a pointer to a cell (with caveats for
immediates, correct?) - I'd misinterpreted the bits about a cell
consisting of, IIRC, 4 words and assumed that the 4-word block itself
was returned (typedef'ed as an SCM), rather than a pointer to the cell
on the heap.  Since that's the case then only the pointer is overwritten
and the cell containing the pointer to the malloc'ed string is still
sitting in the heap and would be collected properly.

Thanks - now I can sleep at night again. :)

-- 
Michael J. Barillier   ///   http://www.blackwolfinfosys.net/~blackwolf/
.O.  |  ``Experience with many protocols has shown that protocols with
..O  |  few options tend towards ubiquity, whereas protocols with many
OOO  |  options tend towards obscurity.''  -- RFC 2821


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel