test_with_coverage not exiting on Windows Github actions with Dart 3.4.0

[dcharkes]

test_with_coverage not exiting on Windows Github actions with Dart 3.4.0

[bkonyi]

I created a virtual D:\ drive on my cloudtop and it looks like I can reproduce:

PS D:\foo> dart pub global run coverage:test_with_coverage --package . --package-name foo
00:00 +0: loading test\foo_test.dart
00:00 +0: test\foo_test.dart: calculate
00:00 +1: All tests passed!

[dcharkes]

This seems to be an issue with Dart 3.4.0 stable, Dart 3.3.0 stable works fine.

[liamappelbe]

Doesn't seem to have anything to do with the github bots. This user is seeing it locally: #489

[rainyl]

It seems no Dart VM service will be started,

output of 3.19.6:

❯ dart pub global run coverage:test_with_coverage --package . --package-name opencv_dart
The Dart VM service is listening on http://127.0.0.1:8181/
The Dart DevTools debugger and profiler is available at: http://127.0.0.1:8181/devtools?uri=ws://127.0.0.1:8181/ws
00:00 +0: loading test\calib3d_test.dart

but with 3.22:

❯ dart pub global run coverage:test_with_coverage --package . --package-name opencv_dart
00:00 +0: loading test\calib3d_test.dart

Maybe that's why the tests are finished but it won't exit.

[a-siva]

//cc @bkonyi , could some of the recent changes about how dds is started from the Dart CLI be contributing these hangs (from the comment above it appears that dds is not starting up.

[bkonyi]

Seems like I missed the CC for this. I'll take a look tomorrow.

[bkonyi]

I'm unable to reproduce at HEAD (Dart SDK version: 3.6.0-edge.5e8ee777729a34187815465ad756079dbe6d601a (main) (Tue Jul 9 14:50:59 2024 +0000) on "windows_x64"). Will try an older version to see if I can reproduce on 3.4.

[bkonyi]

I'm also unable to reproduce on 3.4.0 and 3.4.4.

[bkonyi]

I'm also unable to reproduce with the Dart SDK from Flutter's stable branch. I'll need more details about the environments we're seeing failures in to be able to make any progress on this.

[a-siva]

I'm also unable to reproduce with the Dart SDK from Flutter's stable branch. I'll need more details about the environments we're seeing failures in to be able to make any progress on this.

Have you tried it on Windows because the original report in #489 indicated they saw it on Windows 10.

[dcharkes]

Here is a reproduction from GitHub actions, still hanging with the latest stable:

• https://github.com/dart-lang/native/actions/runs/9861176859/job/27229049028?pr=1274

(Feel free to mess around with PRs on that repo adding stuff to .github/workflows/native.yaml.)

I have no clue what the environment is on the GitHub actions.

@rainyl Could you provide more details on what reproduces this locally for you?

Some observations from that report:

• The dart is from a Flutter SDK
• The local is zh-CN

[dcharkes]

Maybe we could try running GitHub actions locally with something like https://github.com/nektos/act.

[bkonyi]

I'm also unable to reproduce with the Dart SDK from Flutter's stable branch. I'll need more details about the environments we're seeing failures in to be able to make any progress on this.

Have you tried it on Windows because the original report in #489 indicated they saw it on Windows 10.

Yes, I've been running this on a Windows 11 cloudtop.

It looks like there could be two drives involved based on the GitHub action logs. Maybe the fact that the native repo is cloned on D:\ but the SDK is on C:\ is causing issues.

[bkonyi]

This should have been fixed by dart-lang/sdk@66b9bf5, which was CP'd into beta before the stable release. I'll need to investigate what's going on here...

However, I have confirmed that this is fixed at HEAD since we're using dart development-service to launch DDS rather than manually building a path to dds.dart.snapshot. Maybe it's just worth cherrypicking dart-lang/sdk@e82ff48 if we don't think it's too complicated? WDYT @a-siva?

[a-siva]

However, I have confirmed that this is fixed at HEAD since we're using dart development-service to launch DDS rather than manually building a path to dds.dart.snapshot. Maybe it's just worth cherrypicking dart-lang/sdk@e82ff48 if we don't think it's too complicated? WDYT @a-siva?

The change itself looks very small and I agree it is worth cherry picking into the stable release to fix the issue. Hopefully the change has no other side effect.

[bkonyi]

So it looks like we might have to CP both dart-lang/sdk@e82ff48 and dart-lang/sdk@c1dc26a for this to be properly resolved.

However, the actual fix is actually fairly simple, and involves updating _getDevToolsAssetPath() in DDS to the following:

Uri _getDevToolsAssetPath() {
  final dartDir = File(Platform.executable).parent.path;
  final fullSdk = dartDir.endsWith('bin');
  return Uri.file(
    fullSdk
        ? path.absolute(
            dartDir,
            'resources',
            'devtools',
          )
        : path.absolute(
            dartDir,
            'devtools',
          ),
  );
}

This replaces the old logic for detecting artifacts in SDK, which was very similar to the logic found in the VM service before dart-lang/sdk@66b9bf5. This also fixes an exception that could be thrown on Windows when trying to call toFilePath() on the returned URI. Would it be possible to land the above change directly to beta/stable without a corresponding change on main to avoid having to CP two changes that introduce new functionality to get the fix?

[rainyl]

@rainyl Could you provide more details on what reproduces this locally for you?

Sorry for the late reply

It looks like there could be two drives involved based on the GitHub action logs. Maybe the fact that the native repo is cloned on D:\ but the SDK is on C:\ is causing issues.

This is it, I developed on a virtual disk mounted as D:\ and the flutter SDK was installed in C:\ just like github actions.

Thanks for your efforts and hope this can be fixed soon so I can upgrade to newer version. ❤️

[a-siva]

@rainyl will you be able to continue development with the work around of not using a different drive until Dart 3.5 beta 2 is released (I believe Jul 10th 2024 is the release date)?
Since the cherry pick into stable is not a direct cherry pick of a change made and tested in the main branch, but a special fix I would prefer if we did not do that.

[rainyl]

@rainyl will you be able to continue development with the work around of not using a different drive until Dart 3.5 beta 2 is released (I believe Jul 10th 2024 is the release date)?
Since the cherry pick into stable is not a direct cherry pick of a change made and tested in the main branch, but a special fix I would prefer if we did not do that.

No problem, thanks~ 😄