Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

core dump when passing a slice to a generic inout formal #17241

Closed
mppf opened this issue Feb 23, 2021 · 2 comments · Fixed by #17270
Closed

core dump when passing a slice to a generic inout formal #17241

mppf opened this issue Feb 23, 2021 · 2 comments · Fixed by #17270

Comments

@mppf
Copy link
Member

mppf commented Feb 23, 2021

The compiler is creating code that seg-faults at runtime when passing a slice to a generic inout formal.

Steps to Reproduce

Source Code:

proc f(inout arg) {
  writeln("in f, arg= ", arg);
  arg = 1;
}
{
  var A:[1..10] int;
  ref slice = A[1..3];
  f(slice);
  writeln(slice);
  writeln(A);
}

In 1.22, the program runs cleanly under valgrind and prints:

in f, arg= 0 0 0
1 1 1
1 1 1 0 0 0 0 0 0 0

In 1.23, the program segfaults.

The issue started with 8ef988d / PR #16143 and was not resolved in PR #16180.

Associated Future Test(s):
test/functions/intents/inout/in-conversion-inout-slice-formal-generic.chpl #17231

mppf added a commit to mppf/chapel that referenced this issue Feb 23, 2021
including the case shown in issue chapel-lang#17241.

---
Signed-off-by: Michael Ferguson <mppf@users.noreply.github.com>
mppf added a commit to mppf/chapel that referenced this issue Feb 23, 2021
including the case shown in issue chapel-lang#17241.

---
Signed-off-by: Michael Ferguson <mppf@users.noreply.github.com>
mppf added a commit that referenced this issue Feb 24, 2021
Fix inout according to out changes and add a warn-unstable warning

This is a follow-up to PRs #16990 and #17092.

This PR takes the following steps:
 * adds `--warn-unstable` warnings for `=` declared for extern types
   (since this might require `init=` as well in the future (as a
   follow-up to #17092.)
 * Per discussion in #16554 and from the idea that `inout` should behave
   as a combination of `in` and `out`, adjusts function resolution to
   only consider the `in` portion of `inout` when choosing candidate
   functions. (If there is a problem with the `out` portion, it will be
   reported at the `=` call that is added back to the actual). This is a
   follow-up to  #16990.
 * Adds tests for several of these cases, including an example discussed
   in issue #16576.

This effort exposed a latent bug (since 1.23) - see *core dump when
passing a slice to a generic inout formal* #17241.

- [x] full local futures testing
- [x] primers pass with valgrind+verify and do not leak

Reviewed by @vasslitvinov - thanks!
@bradcray
Copy link
Member

The role of slices in this issue catches my attention. Let me know if it's something that would benefit from my help.

@mppf
Copy link
Member Author

mppf commented Feb 25, 2021

In 1.22, the formal is a ref to a slice array, and the formal-tmp is a DR array.
But now, the formal-tmp (at the call site) is a DR array but the formal in f is a slice array. We need to arrange for the formal to be a DR array.

mppf added a commit that referenced this issue Mar 1, 2021
Look inside refs when instantiating copy type for in/inout

Resolves #17241

The issue is that the compiler resolves signatures for `in` / `inout`
functions as `ref` types today. But the code in `getInstantiationType`
that was intended to handle type conversion when instantiating (from say
`sync int` to `int` or array slice to non-slice array -- to match
`var x = actualArg` behavior) was not handling the case that the
formal type is a `ref`.

Reviewed by @e-kayrakli - thanks!

- [x] full local testing
- [x] primers pass with valgrind+verify and do not leak
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants