Skip to content

[cfe/vm] Soundness issue in the vm #46390

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

Closed
eernstg opened this issue Jun 17, 2021 · 1 comment
Closed

[cfe/vm] Soundness issue in the vm #46390

eernstg opened this issue Jun 17, 2021 · 1 comment
Assignees
Labels
legacy-area-front-end Legacy: Use area-dart-model instead. P2 A bug or feature request we're likely to work on soundness type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)

Comments

@eernstg
Copy link
Member

eernstg commented Jun 17, 2021

Consider the following program:

class A {
  num foo(num n) {
    print(n.runtimeType);
    return 1.1;
  }
}

abstract class B<X> {
  X foo(X x);
}

class C extends A with B<num> {}

void main() {
  B<Object> b = C();
  b.foo(true);
}

Using tools from dea0488:

The program is accepted by the analyzer (which is OK), and it is accepted by the CFE (which is OK, but the generated kernel code does not include an implicitly induced type checking stub for foo in C, and that's probably a bug).

However, when the program is executed on the vm there is no dynamic error, it just prints 'bool', and that shows that we've encountered a soundness violation.

I'll mark this issue as 'area-front-end', because the generated kernel code seems to be wrong (I would have expected _C&A&B or C to contain an implementation of foo where there required dynamic type check on the actual argument is performed):

abstract class _C&A&B extends self::A implements self::B<core::num> /*isAnonymo>
  synthetic constructor •() → self::_C&A&B
    : super self::A::•()
    ;
  abstract method foo(generic-covariant-impl core::num x) → core::num;
}
class C extends self::_C&A&B {
  synthetic constructor •() → self::C
    : super self::_C&A&B::•()
    ;
}

However, dart2js does raise the dynamic error, so maybe the backends are responsible for part of the work?

@eernstg eernstg added type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) soundness legacy-area-front-end Legacy: Use area-dart-model instead. labels Jun 17, 2021
@johnniwinther johnniwinther self-assigned this Jun 17, 2021
@johnniwinther johnniwinther added the P2 A bug or feature request we're likely to work on label Jun 17, 2021
@eernstg
Copy link
Member Author

eernstg commented Jul 8, 2021

About the degree to which this is covered by the language specification: Cf. #46389 (comment) and dart-lang/language#1729.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
legacy-area-front-end Legacy: Use area-dart-model instead. P2 A bug or feature request we're likely to work on soundness type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)
Projects
None yet
Development

No branches or pull requests

2 participants