Test failures on ffi/native_assets/asset_relative_test

[jyameo]

There are new test failures on [vm,dartdev] Support dynamic linking between libraries.

The tests

ffi/native_assets/asset_relative_test RuntimeError (expected Pass)

are failing on configurations

vm-aot-win-release-arm64
vm-aot-win-release-x64

LOGS:

• https://dart-ci.appspot.com/log/vm-aot-win-release-arm64/vm-aot-win-release-arm64/3070/ffi/native_assets/asset_relative_test
• https://dart-ci.appspot.com/log/vm-aot-win-release-x64/vm-aot-win-release-x64/4290/ffi/native_assets/asset_relative_test

[dart-github-bot]

Summary: asset_relative_test in the FFI module fails on Windows ARM64 and x64 after a recent change (commit 903eea6). Runtime errors are reported.

[blaugold]

If I understand ffi_test_functions correctly, it is dynamically linked to dart.exe. With the changes to the dll search path in 903eea6 the executable directory is no longer on the dll search path, and is replaced with the library directory. So if ffi_test_functions.dll is moved somewhere else, than next to dart.exe (which is what the tests do) dart.exe can't be found when loading ffi_test_functions.dll. I still think that the new behavior is what we want, and I can't think of a use case where a user of native assets needs to be able to load dependent dlls relative to the executable. If we cannot remove the dependency on dart.exe from ffi_test_functions.dll we could use AddDllDirectory in the tests that move ffi_test_functions.dll to add the executable directory back to the dll search path.

/cc @dcharkes

[dcharkes]

Thanks for the analysis! 👍

If I understand ffi_test_functions correctly, it is dynamically linked to dart.exe.

I believe that is true. However, to my understanding that should only influence behavior when one of the dart_api.h symbols is accessed. And it is the cause of #40579.

With the changes to the dll search path in 903eea6 the executable directory is no longer on the dll search path, and is replaced with the library directory. So if ffi_test_functions.dll is moved somewhere else, than next to dart.exe (which is what the tests do) dart.exe can't be found when loading ffi_test_functions.dll.

Ah, so you're saying it's trying to eagerly load dart.exe.

This is kind of an artifact of the testing, because we happen to use a dll that is dynamically linked to the Dart API.

I see two solutions:

1. Create a new dll for this test, that doesn't use the Dart API, and therefore doesn't have to link to dart.exe.
2. Split the current ffi_test_functions.dll in ffi_test_functions_vmspecific.dll and ffi_test_functions.dll. We already have have the split in the .cc file. But this requires visiting all the tests to see if they're calling functions from the one or the other.

Both require you to add an extra dylib in runtime/bin/BUILD.gn similar to shared_library("ffi_test_functions") {.

I still think that the new behavior is what we want, and I can't think of a use case where a user of native assets needs to be able to load dependent dlls relative to the executable.

Agreed! The "relative" does not mean relative to dart.exe, it means relative to (1) the dart file passed to dart.exe, or (2) the kernel file passed to dart.exe, or (3) the aotsnapshot passed to dartaotruntime.exe or (4) the executable created by dart compile exe or dart build. For 1,2,3 the exe path itself should be irrelevant.

[blaugold]

@dcharkes I tried fixing #40579 instead, which should solve this issue too: https://dart-review.googlesource.com/c/sdk/+/400582

[dcharkes]

Ah nice! Yeah this a great solution for running the tests.

(It's somewhat similar to dart_api_dl.h and dart_api_dl.c which are also compiled into dylibs. But these also solve that the Dart symbols are hidden in the Flutter executable.)