Isolate-local native callables create spurious exception in debugger when returning null

[simolus3]

Consider this Dart program:

import 'dart:ffi';

void main() {
  final function = NativeCallable<Void Function()>.isolateLocal(() {})
    ..keepIsolateAlive = false;
  final asDart = function.nativeFunction.asFunction<void Function()>();
  asDart();
}

Running dart run that_program.dart completes without error logs and exits with code zero. Running that program with a debugger (dart run --observe that_program.dart) doesn't:

The Dart VM service is listening on http://127.0.0.1:8181/xvWAL9_XNRg=/
The Dart DevTools debugger and profiler is available at: http://127.0.0.1:8181/xvWAL9_XNRg=/devtools?uri=ws://127.0.0.1:8181/xvWAL9_XNRg=/ws
vm-service: isolate (2709096504744891) 'main' has no debugger attached and is paused due to exception.  Connect to the Dart VM service at http://127.0.0.1:8181/xvWAL9_XNRg=/ to debug

The exception is an ArgumentError about return_value being null, it has the trace of the asDart() call. The exception does not happen when the native callable returns a non-null value, but returning void is pretty useful.

This appears to be a regression on Dart 3.4.

[dart-github-bot]

Summary: When using isolate-local native callables returning null in a debugger, a spurious ArgumentError is thrown, even though the program runs without errors when not debugged. This issue appears to be a regression introduced in Dart 3.4.

[a-siva]

@simolus3 I was trying to reproduce the problem you mention above using top of tree Dart CLI and I don't seem to be getting the ArgumentError exception you mention above, the program seem to terminate after I connect the debugger and resume the program.

[mraleph]

Most likely fixed a8dcef9173dac8d453ff39f543ae20bf113ce4c6 - requires a cherry-pick I suppose?

cc @dcharkes, this also has a way to create a regression test, which was missing from the original CL? debugger attached seems to be a missing piece, somehow? worth checking what is going on here and expanding our test accordingly to increase coverage.

[a-siva]

@a-siva needs to create a cherry pick for it and this issue can then be closed.

[a-siva]

The change https://github.com/dart-lang/sdk/commit/a8dcef9173dac8d453ff39f543ae20bf113ce4c6 requires https://dart-review.googlesource.com/c/sdk/+/360882 which is a huge change and I am reluctant at this point to include that into a cherry pick for stable (Dart 3.4).

@simolus3 would it be possible for you to switch to a newer version of Dart (3.5) ?

[simolus3]

There's a workaround for this issue (just return a bogus value in the void-returning callback and let that get dropped by the ffi implementation). So if a cherry-pick is unfeasible I'll just wait for 3.5 and then undo my workarounds.

[mkorbel1]

I'm hitting this issue as well with some pre-compiled libraries that I do not own, so the workaround of returning a bogus value doesn't work for me. I guess that leaves using an older version of Dart or jumping to/waiting for 3.5. Just commenting since the issue got closed.

[simolus3]

I've closed the issue because my problem was addressed by that, I didn't consider that others may be having the same issue - sorry!

I've re-opened it, so it's the call of the Dart team to decide whether it gets closed as is or if we see a cherry-pick or anything else that may still have to be done here.

[mkorbel1]

@simolus3 no problem, thanks!

[a-siva]

@mkorbel1 is jumping/waiting for 3.5 an option for you, as mentioned earlier in a comment cherry picking such a large change into 3.4 seems risky.

[mkorbel1]

@a-siva since this only happens while debugging, I've resorted to debugging via print statements as necessary, which has been enough so far. If I get fed-up enough, then I can try 3.5 beta. I'd categorize it as annoying, but not a major block, as long as 3.5 contains the fix and 3.5 is not too far away.

[simolus3]

I'll close this since 3.5 has been out for a while...