Dart_ExecuteInternalCommand("gc-now") broken on *-precomp-win-*

[ghost]

Several test are crashing on precompiled Windows, while calling Dart_ExecuteInternalCommand("gc-now"):

vm/dart_2/unboxed_param_args_descriptor_test broke (Pass -> Crash, expected Pass)
vm/dart_2/unboxed_param_tear_off_test broke (Pass -> Crash, expected Pass)
vm/dart_2/unboxed_param_test broke (Pass -> Crash, expected Pass)
ffi_2/vmspecific_function_callbacks_test broke (Pass -> Crash, expected Pass)
ffi_2/vmspecific_function_gc_test broke (Pass -> Crash, expected Pass)
ffi_2/vmspecific_object_gc_test broke (Pass -> Crash, expected Pass)
ffi_2/vmspecific_regress_37100_test broke (Pass -> Crash, expected Pass)
ffi_2/vmspecific_regress_37511_callbacks_test broke (Pass -> Crash, expected Pass)
ffi_2/vmspecific_regress_37511_test broke (Pass -> Crash, expected Pass)
ffi_2/vmspecific_regress_37780_test broke (Pass -> Crash, expected Pass)

To replicate this, you will currently need to remove a condition as described in #46059, after which the tests above will fail.

Edit: This appears to likewise affect other Dart_ExecuteInternalCommand(..) calls, and probably other functions as well.

[ghost]

With the caveat that I'm entirely new to debugging on Windows, here are some preliminary findings on this issue.

Reproducing steps:

0. I did a one-time setup procdump -ma -i c:\dumps to capture crashes.
1. Built python3 tools/test.py --build -k -n dartkp-win-debug-x64 ffi_2/vmspecific_function_gc_test/2
2. Ran out\DebugX64\dart_precompiled_runtime.exe --deterministic --optimization-counter-threshold=500 --enable-testing-pragmas --ignore-unrecognized-flags --packages=C:\src\dart\sdk\.packages C:/src/dart/sdk/out/DebugX64/generated_compilations/dartkp-win-debug-x64/tests_ffi_2_vmspecific_function_gc_test/out.aotsnapshot to generate the new dump.

Opening the resulting C:\dump\*.dmp in 'Debug Diagnostic Tool' I then see:

In dart_precompiled_runtime.exe_210519_133507.dmp the Module C:\src\dart\sdk\out\DebugX64\dart.exe 
has caused an access violation exception (0xC0000005) when trying to execute instructions from a 
non-executable address at memory location 0x01301290 on thread 6 

Thread 6:

 0x01301290
dart!dart::Mutex::Lock+e
dart!dart::Scavenger::AbandonRemainingTLAB+8e
dart!dart::Heap::CollectOnNthAllocation+2f
dart!Dart_ExecuteInternalCommand+1f9
ffi_test_functions!MinInt64+15

Which makes it look like an issue with Mutex::Lock.

[ghost]

@mraleph this seems like something that might be up your alley. Any ideas what's going on here?

[ghost]

The code executing at the time is:

sdk/runtime/vm/os_thread_win.cc

Lines 247 to 248 in 99679b5

	void Mutex::Lock() {
	AcquireSRWLockExclusive(&data_.lock_);

Which is Windows API.

My guess is that it's a runtime linking issue (not too dissimilar to #40579), and we end up calling some garbage address where the Win. API should be?

[ghost]

On dcharkes' suggestion I tried Debug in VisualStudio.
One unexpected finding there is that ffi_test_function.dll is linked against dart.exe. Which means that when dart_compiled_runtime.exe loads ffi_test_function.dll that in turn loads dart.exe, which seems fishy to me.

More speculation: perhaps we need to produce two different ffi_test_function.dlls - one for each dart binary?

Edit:
Ah, I see the build file says as much:

sdk/runtime/bin/BUILD.gn

Lines 1050 to 1052 in 28c784d

	if (is_win) {
	# TODO(dartbug.com/40579): This wrongly links in dart.exe on precompiled.
	libs = [ "dart.lib" ]

Switching the above line over to dart_precompiled_runtime.lib also fixes the issue, confirming the theory.

[mkustermann]

This issue's title suggests that Dart_ExecuteInternalCommand is broken on *-precomp-win-* - but that function is working fine if used correctly.

Could we close this as duplicate of #40579?

[ghost]

The specific issue here (and in #46059) has now been addressed, and any remaining work is related to #40579.