sass/libsass — pull request #564 by mgreter (2014-10-21 20:42:51+00:00)
Title: Fixes memory leaks with C functions and Sass_Values

Was out hunting and found some memory leaks. This only affects C Interface bindings and probably only the ones that implement custom `c_functions`, though. AFAIK `Sass_Values` are only used as an intermediate representation to exchange data between C and C++.

I've recently added more native `Sass_Value` representations for `perl-libsass` (aka a map is a hash, and list is an array). I was pretty sure that I had introduces some leaks myself, therefore I went into the woods to hunt them down. It turned out, that some of the leaks were actually from libsass. Well, sort off, since I could not do anything after I returned a `Sass_Value` back to `libsass` via a custom `c_function`. As it turns out, some `Sass_Values` (created via `make_sass_*`) [allocate](https://github.com/sass/libsass/blob/master/sass.cpp#L141) [additional](https://github.com/sass/libsass/blob/master/sass.cpp#L150) [memory](https://github.com/sass/libsass/blob/master/sass.cpp#L131) on the heap that needs to be freed later.

There is some room for discussion, but I tried to obey the fallowing rules:
- If you get a Sass_Value from libsass, you have to take care to free it
- If you pass a Sass_Value back to libsass, libsass will take care to free it

This may not be optimal for everybody.
- Libsass could free c_args on its own in [eval.cpp](https://github.com/mgreter/libsass/compare/fix/c-sass-value-mem-leak?expand=1#diff-f851db273deb17a2efe1c7cdeaea1ae0R371). I guess there is no real reason why an implementor would like to have the memory to stick around (he should make a copy anyway).
- I cannot return the same `Sass_Value` instance from my binding twice, since libsass will free the memory accociated with it. This is not really a problem for `perl-libsass` since it copies the data anyway into perl data structures.

WIth this additions my pretty extensive [smoke test](https://github.com/sass/perl-libsass/blob/fix/c-sass-value-mem-leak/t/smoke/mem-leaks.pl) does not exhibit one leaked byte, even after 200000 iterations when using custom `c_functions` and passing various types of `Sass_Values` around.

I am somehow in favor of having libsass freeing the `Sass_Values` it passes to me, but it somehow defeats the rule that `Sass_Value` responsabilites to free are passed to the receiver. It would just save me from having it to free myself and could probably prevent someone else to step into this trap.
@hcatlin, @akhleung: If you want that behaviour I can ammend this commit to include `free_sass_value(c_args);` in `eval.cpp`!