Chapel: "Extra" deinit / clarification on init/deinit and copy/move behavior

[nspark]

Summary of Problem

BLUF: With writeln tracing, I was seeing two deinit calls, but only one init call.

I'd appreciate some help understanding the behavior of the following code. I _think_ this touches on init/deinit and copy/move behavior. At the least, it was not what I was expecting.

Steps to Reproduce

Given the following Chapel source (deinit-mem-test.chpl):

// assuming you can print pointers...
// see https://github.com/chapel-lang/chapel/issues/7097

record Foo {
  var mem: c_ptr(uint(64));

  proc init(size: int) {
    mem = c_calloc(uint(64), size);
    super.init();
    writeln("Foo.init(int)");
  }

  proc deinit() {
    writeln("Foo.deinit()");
    c_free(mem);
  }

} // record Foo

proc fnCall(foo: Foo) {
  writeln(foo);
}

proc fnCallWithCopy(foo: Foo) {
  // Is this a copy or a move?
  var copy = foo;
  writeln(copy);
}

{
  var foo = new Foo(1024);
  fnCall(foo);
}
writeln();

{
  var foo = new Foo(1024);
  fnCallWithCopy(foo);
}
writeln();

Testing this was helpful with the following env-vars set:

export CHPL_MEM=cstdlib
export MALLOC_CHECK_=1

Compiling and output (with comment):

$ chpl deinit-mem-test.chpl && ./deinit-mem-test
Foo.init(int)
(mem = <some address>)
Foo.deinit()

Foo.init(int)
(mem = <some address>)
Foo.deinit()
Foo.deinit() # "extra" deinit() --> free() on invalid pointer

Configuration Information

This was using master as of b4d156e.

[lydia-duncan]

@mppf - did you have any thoughts on this? It seems like we should have been getting an error for not defining a copy initializer, but if we define one, it never gets called.

[mppf]

The var copy = foo; in fnCallWithCopy should be copying the record. I agree that with the code as-written, there is no copy initializer defined and so it should not compile.

I havn't dug in to the issue but I have a guess about what's going wrong. This looks related to (caused by?) PR #6103 which was a temporary workaround. I just don't know if any progress has been made since then. (Of course, this could be a totally separate issue as well).

One reasonable experiment to try here would be to manually define initCopy and/or autoCopy for the record to see if that patches up the issue.

[noakesmichael]

This bug was related to, but distinct from, a known issue in which a copy-init was being skipped
when it should not have. Both problems are now fixed on master.

[mppf]

Thanks @noakesmichael !