in reply to memory leak in eval_pv?

eval_*(...) take the same flags as their cousins call_*(...) in that you must specify G_DISCARD to discard the return value of the eval or you'll leak SV's with refcount one.

Update: After speaking with ysth I learned that eval_pv(...) doesn't care about G_DISCARD. While my initial diagnosis was correct, you're not freeing the SV returned by eval_*(...), a solution that works is:

SvREFCNT_dec(eval_pv(...));

Replies are listed 'Best First'.
Re^2: memory leak in eval_pv?
by lightspeed (Initiate) on May 16, 2007 at 11:13 UTC
    Hi Trizor, Many thanks for your reply - alas this did not seem to fix the leak. The code I have now is:
    #include <EXTERN.h> #include <perl.h> static PerlInterpreter *my_perl; main (int argc, char **argv, char **env) { STRLEN n_a; int i; char *embedding[] = { "", "-e", "sub fred {1;};" }; my_perl = perl_alloc(); perl_construct( my_perl ); perl_parse(my_perl, NULL, 3, embedding, NULL); perl_run(my_perl); for(i=0; i < 10000000; i++) { SvREFCNT_dec(eval_pv("1;", TRUE)); } perl_destruct(my_perl); perl_free(my_perl); }
    and compiled with perl 5.8.3 still leaks. In a previous attempt (before I posted) I tried assigning the eval_pv() to an SV* and explicitly calling SV_free on it (and also setting it mortal with sv_2motral) but neither of these helped. I was coming to the conclusion that the leak may be inside eval_pv/sv iteself so I thought I'd post here to see if anyone else had seen similar issues. I guess the thing to try next is to build the latest 5.8.8 perl and try it with that. Many thanks, Shaun.
      Just to wrap this one up.... It appears that eval_pv (and eval_sv) return a mortal SV* that must be cleaned up by "topping and tailing" the call to eval_pv with:
      ENTER; SAVETMPS; value = (eval_pv("1;", TRUE)); FREETMPS; LEAVE;
      The assignment SV* value is required, else errors about freeing unreferenced value are generated. Shaun.