Isolate group callbacks can capture mutable `late final` variables.

[alexmarkov]

Example:

import 'dart:ffi';

void main(List<String> args) {
  late final List<String> list;
  final callback = NativeCallable<Void Function()>.isolateGroupBound(() {
    list.add('hey');
  });
  list = [];
  callback.nativeFunction.asFunction<void Function()>().call();
  print(list);
  callback.close();
}

late final variables can be initialized later, after isolate group callback is created, so they are somewhat mutable. This would bypass check that values of captured variables are shareable and would allow sharing arbitrary mutable Dart objects between isolate group callback and Dart isolate.

/cc @aam

[aam]

I am not sure I would call late final variables mutable. They have to be written and initialized before they are used, but initialized only once.

[alexmarkov]

It is a VM's implementation detail that they are mutable: uninitialized late variables and fields have a special Object::sentinel() value and their value is changed during initialization. So, if late final variables are allowed to be captured, then it is not enough to inspect values of captured variables when isolate group callback is created, as they may change later to reference arbitrary non-shareable Dart objects.

[alexmarkov]

A slightly modified example which runs multiple callbacks accessing the same List object concurrently and crashes:

import 'dart:ffi';
import 'dart:isolate';

void main(List<String> args) async {
  late final List<String> list;
  final callback = NativeCallable<Void Function()>.isolateGroupBound(() {
    for (int i = 0; i < 10000; ++i) {
      list.add('hey');
      list.removeLast();
    }
  });
  list = [];
  final nativeFunction = callback.nativeFunction;
  final futures = <Future>[];
  for (int i = 0; i < 20; ++i) {
    futures.add(Isolate.run(() {
      nativeFunction.asFunction<void Function()>().call();
    }));
  }
  await futures.wait;
  print(list);
  callback.close();
}

===== CRASH =====
si_signo=Segmentation fault(11), si_code=SEGV_ACCERR(2), si_addr=0x7fa04950adf0
version=3.11.0-edge (main) (Unknown timestamp) on "linux_x64"
pid=1659202, thread=1659216, isolate_group=main(0x55eb46450950), isolate=(nil)((nil))
os=linux, arch=x64, comp=no, sim=no
isolate_instructions=55eb4085a6a0, vm_instructions=55eb4085a6a0
fp=7fa02a3fe1a0, sp=7fa02a3fe160, pc=7fa04870474d

===== CRASH =====
si_signo=Segmentation fault(11), si_code=SEGV_ACCERR(2), si_addr=0x7fa04950adf0
Aborting reentrant request for stack trace.

[aam]

ah, that aspect I believe is captured by existing #61962

[alexmarkov]

@aam What kind of additional dynamic check would help for this example? When isolate group callback is created, we check closure context and the variable has a sentinel value which passes the check. The callback does not modify the variable - only main isolate does, and the variable is not declared as vm:shared. We can probably flag uninitialized sentinel value as not passing the check, but that might be too restricted.

From the spec dart-lang/language#4515:

Closures which capture only final variables containing deeply immutable
instances are deeply immutable.

We should probably explicitly exclude late final variables from the definition of deeply immutable instances in the spec.
/cc @mraleph

[aam]

the variable has a sentinel value which passes the check.

I was thinking that sentinel values should fail the "deeply-immutability" check.

[mraleph]

I think we should start by outlawing late. I will update the spec.