Closed radical closed 1 year ago
Tagging subscribers to 'arch-wasm': @lewing See info in area-owners.md if you want to be subscribed.
Author: | radical |
---|---|
Assignees: | - |
Labels: | `arch-wasm`, `blocking-clean-ci`, `test-failure` |
Milestone: | - |
cc @pavelsavara
Findings:
marshal-to-cs.ts, in _marshal_cs_object_to_cs () there is this case:
else if (value instanceof Error) {
set_arg_type(arg, MarshalerType.JSException);
const js_handle = mono_wasm_get_js_handle(value);
set_js_handle(arg, js_handle);
}
in JSMarshalerArgument.Exception.cs, this is decoded as:
JSObject? jsException = null;
if (slot.JSHandle != IntPtr.Zero)
{
// this is JSException round-trip
jsException = JSHostImplementation.CreateCSOwnedProxy(slot.JSHandle);
}
string? message;
ToManaged(out message);
so the sender doesn't set the message param that the receiver is trying to decode. is that a bug ? the JSMarshalerArgument struct is allocated using localloc, so its not initialized, so ToManaged(out string) tries to read a random value here:
fixed (void* argAsRoot = &slot.IntPtrValue)
{
value = Unsafe.AsRef<string>(argAsRoot);
}
creating a random object reference.
I'm on it
bug for sure, many thanks!
This should only happen when somebody is returning JavaScript Error
instance as on JSImport with System.Object
return type.
The test which we have stack trace for is JSImportException
which is only marshaling via strongly typed System.Exception
and marshal_exception_to_cs
.
@vargaz I wonder if the random reference could have survived in memory from some of the previous tests.
Could such memory corruption also cause https://github.com/dotnet/runtime/issues/77334 ?
This is breaking on rolling builds. Build, and log:
Full trace is at https://gist.github.com/radical/03fe923e8cc760fc0853b7b8fe1b0aeb .
cc @pavelsavara @maraf @vargaz I think this might be related to https://github.com/dotnet/runtime/issues/77334 which is getting hit regularly on CI.
Report
Summary