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

closure built after get is subject to stale context #434

Closed
albertnetymk opened this issue May 23, 2016 · 2 comments · Fixed by #520
Closed

closure built after get is subject to stale context #434

albertnetymk opened this issue May 23, 2016 · 2 comments · Fixed by #520
Assignees

Comments

@albertnetymk
Copy link
Contributor

def id(x:int) : int
  x

class Test
  def f() : int
    0
  def g(f: int -> int) : void
    ()

class Main
  def main():void {
    repeat i <- 1000 {
      let t = new Test;
      get t.f();
      let f = \(x:int) -> id(x);
      t.g(f);
    }
  }
@supercooldave
Copy link

I don't really understand what this means.
What is the bug?
What error (message) is produced?

@kikofernandez
Copy link
Contributor

@supercooldave the error message is:

Process 41948 launched: './error' (x86_64)
Assertion failed: (obj), function gc_sendobject, file libponyrt/gc/gc.c, line 165.

This is a bug in the tracing of the closure (I believe), which doesn't get a new context (pony_ctx()) after the call get. The error is produced when the Main actor gets blocked, is un-scheduled, gets fulfilled, and now a different pthread continues the execution. The context contains information about the current actor, scheduler, etc which is thread-local information. Since another pthread has resumed the actor, this information will not match whatever it was before. (this is my understanding of the issue)

@albertnetymk albertnetymk self-assigned this May 24, 2016
@kikofernandez kikofernandez self-assigned this Jun 15, 2016
EliasC pushed a commit that referenced this issue Jun 16, 2016
* fix tracing ParT types

the tracing function for the ParT types was not correctly generated and
caused runtime errors. The issues that have been fixed are shown below
and this closes #393:

- fix >> combinator with correct trace function
  the generated trace function was not correct, causing runtime crashes

- fix trace function for extract combinator was not correct and was
  tracing array_types. the trace function of the extract combinator was
  always set to be an array; this is not the case, as that trace
  function is used to indicate the trace function of the returned array.
  the function function gets the runtime base type of party, e.g. `Par
  t` has runtime type `t` and a `Par (Par t)` has runtime type `Par t`,
  since the array will contain `Par t`s.

- fix join combinator. removed assertion. In the following scenario
  (P p1 p2), an assertion tests that the tracing function of p1 and p2
  should be the same. this is not true, as p1 may be a (V 32) and p2 may
  be a (F f), which should have different tracing functions.

* refactor tests to not-used `extract`

refactor tests in ParT to avoid the use of the `extract` function. this
is due to an issue (#434) related to futures. the sequence test omits
the use of extract, and the liftf test has been re-written to avoid that
as well. tests that cannot avoid the use of `extract` have been disabled
and will be re-enable as soon as this works.

* remove `extract` from the language

* remove `extract` from documentation
albertnetymk pushed a commit that referenced this issue Jul 28, 2016
* Refresh context only after context switch

This commit fixes #434. It tries to keep the number of calls to pony_ctx
to a minimum by only updating after a (potential) switch of threads, but
then doing it "across the stack" by using a double pointer to a stack
variable in the `run` function of the scheduler.

* Manual caching of *ctx
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants