Memory management bug probably in tit_lazy, likely related to futures

[kaeluka]

This program demonstrates a bug, pbly in the futures implementation:

program.enc:

#! /usr/bin/env encorec -run

class Foo {
  def bar() : int {
    print "hello";
    84
  }

  def baz() : int {
    this.bar()
  }
}

class Main {
  def main() : void {
    let l = new Foo in {
        print get l.baz();
        print get l.baz()
    };
  }
}

When run in a loop, the program will output:

$ while [ true ]; do ./program.enc || break ; done
hello
84
hello
84
-- snip --
hello
hello
84
-- snip --
...

In the last lines, you see that a 84 did not appear. As far as I can tell, the future get did not return, instead the executable returns with a normal (!) exit, as the break does not get triggered.

Edit: Also, sometimes I get

$ ./program.enc
hello
report(845,0x7fff7322b310) malloc: *** error for object 0x7fbcb3600338: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug    ...

[EliasC]

I get the same kind of behavior, as well as the occasional

$ ./foo.enc
hello
84
hello
foo(69137,0x7fff79a9b310) malloc: *** error for object 0x7fc31bc04128: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug

Could it have to do with GC of futures?

[TobiasWrigstad]

I may have found this bug. It seems that under certain circumstances, we are freeing a lazy_tit too eagerly. You could try to remove the free call in garbage_collect_stack in tit_lazy.c and see if that removes your problem.

[EliasC]

@TobiasWrigstad Removing the free seems to fix the problem! But I guess that this means that we're now leaking something instead... Is this also something that (hopefully) will be fixed with the new future implementation?

[TobiasWrigstad]

Kiko and Albert are rewriting the lightweight threads (not entirely unrelated to futures, but not the same thing either). All tit_* code will soon go.

[kikofernandez]

That’s correct. Moreover, the eager and lazy implementation were broken on Linux. Sometimes the program finish and sometimes it crashes.
Our current implementation (not yet finish) does not crash on Mac nor on Linux.

[kikofernandez]

tested the current implementation. working on Mac and Linux