Fix some minor memory leaks with context options

[mgreter]

Note: Sass_Context is also a Sass_Options, therefore one only needs to call either sass_delete_compiler or sass_delete_options. They're created via sass_make_TYPE_compiler or sass_make_options respectively. Therefore if you use sass_make_options you probably must add the corresponding sass_delete_options now (this ie. is the case with sassc).

[mgreter]

# valgrind --leak-check=full sassc/bin/sassc sassc/foo.scss
==3514== Memcheck, a memory error detector
==3514== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==3514== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==3514== Command: sassc/bin/sassc sassc/foo.scss
==3514==
foo-bar {
  baz: baz; }
==3514==
==3514== HEAP SUMMARY:
==3514==     in use at exit: 0 bytes in 0 blocks
==3514==   total heap usage: 2,403 allocs, 2,403 frees, 166,497 bytes allocated
==3514==
==3514== All heap blocks were freed -- no leaks are possible
==3514==
==3514== For counts of detected and suppressed errors, rerun with: -v
==3514== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

[mgreter]

Currently running valgrind over all spec tests (could take a while):

use strict;
use warnings;

use IPC::Run3;
use File::Find::Rule;

my $root = "libsass/sass-spec/spec";
my @files = File::Find::Rule->file()
            ->name('input.scss')->in($root);

foreach my $file (@files) {
  my $cmd = sprintf('libsass/sassc/bin/sassc %s', $file);
  my $check = sprintf('valgrind --leak-check=yes %s', $cmd);
  run3($check, undef, \ my $out, \ my $err);
  next if $err =~ m/in use at exit: 0 bytes in 0 blocks/;
  warn "got a leak $? !!\n", $err, "#" x 80, "\n";
}

[mgreter]

No further leaks detected via valgrind (ran all spec tests via the script from above). Doesn't say there still exist some more leaks on the C-API level or anywhere else for that matter 🐛

[nschonni]

Do you think it's worth adding valgrind to the CI?

[mgreter]

IMHO to slow for CI, probably even takes too long for CI to complete.