Chapel: segfault after using list.append(union)

[BryantLam]

This program segfaults at end of execution.

use List;

union Union {
  var s: string;
}

record Container {
  var items: list(Union);
}

proc main() {
  var aUnion: Union;
  aUnion.s = "string literal";

  var container = new Container();
  container.items.append(aUnion);

  writeln(container);
}

(items = [(s = string literal)])
Segmentation fault

chpl version 1.20.0 pre-release

[bradcray]

@dlongnecke-cray : Any chance you have time to look into this? Unions do not see much exercise or use within Chapel (and are often on the chopping block to be voted off the island at least until they're significantly re-designed), so it would not surprise me if there was some weird interaction between lists and unions going on here. But I can't guess what it would be given that we don't have valgrind errors with (the limited number of) other union tests in the system.

[cassella]

Don't you? Given the similarity of the valgrind reports, I think this is related to #12405, which has a valgrind future.

Though in my bug, removing the line casting it to a string removed the problem. I get the same valgrind error with this code even after removing the writeln(). So I guess I was too quick to pin my issue on the cast.

[bradcray]

Oh, thanks for connecting those dots, Paul! I'd forgotten that you'd tinkered with (and suffered from) unions recently as well.

[cassella]

It also happens without the involvement of the list type. I get the same valgrind errors passing aUnion to this function instead of a list.append() call:

proc nop(in u) {}

The error doesn't happen with blank intent.

[bradcray]

I'm tagging @mppf on this as well then, since I think he was the last person to mess with the implementation of in intents.

[mppf]

This is not a bug so much as something where the implementation is completely missing. I'm looking at fixing it, but:

• I expect there will be more union bugs
• I am not sure that unions work the way we want them to in the ideal language

[BryantLam]

• I am not sure that unions work the way we want them to in the ideal language

Aside: unions aren't convenient when comparing. For example, unions don't support a == b; you have to compare on the union member instead: a.s == b.s. It's a minor annoyance when a.s will already halt if a doesn't hold an actual member s. (It's kind of similar to force-unwrapping a nilable.)

[mppf]

@BryantLam - I don't think it would be hard to create != and == by default for unions. I'd encourage you to create a separate issue about it, even if it is short.