"Uncaught ExitStatus ExitStatus" Encountered Instantiating New XmlSerializer() [WASM] #10071

ToddGlodek · 2022-10-05T19:53:20Z

ToddGlodek
Oct 5, 2022

Current behavior

In a project that has both a WinUI3 & WASM client, I have many services that make XML-based API calls ( the API calls cannot be converted to JSON ). The WinUI client can make ALL the API calls successfully. However on WASM, one particular API call fails when calling the XmlSerializer constructor. XmlSerializer _ctor takes "System.Type" as an argument - and all my the other custom classes/types can be successfully passed to the _ctor on both WinUI & WASM.

On WASM, just the one of my custom classes/types causes an "Uncaught ExitStatus ExitStatus" report to be displayed in the DEBUG OUTPUT. When this happens the C# code appears to just stop running, but the APP doesnt crash. No error is thrown by the XmlSerializer _ctor, and no further log events are recorded.

Expected behavior

The WASM client should be able to Instantiate an new XmlSerializer() in the same way that WinUI does. At a minimum, a catchable exception should be thrown - rather than the tread just seeming to end.

How to reproduce it (as minimally and precisely as possible)

The following code causes "Uncaught ExitStatus ExitStatus" do be displayed in DEBUG window OUTPUT. Note that "Finished instantiate", "About to invoke", "Failed To DeSerialize" log items never get written.

    private SimulationResult DeSerializeResult(Stream simulationResult)
    {        
        XmlSerializer serializer;
        try {
            this.Log().LogDebug("About to instantiate XmlSerializer");

            /**  This call results in long "Uncaught ExitStatus ExitStatus" report in DEBUG window **/
            serializer = new XmlSerializer(typeof(SimulationResult));

            this.Log().LogDebug("Finished instantiate XmlSerializer");            
        }
        catch (Exception ex)
        {
            this.Log().LogDebug("This never gets called");
            this.Log().LogError(ex, "Failed To DeSerialize Simulation Result");            

            return null;
        }

        try
        {
            this.Log().LogDebug("About to invoke Deserialize() ");

            using (StreamReader reader = new StreamReader(simulationResult))
            {
                SimulationResult simuResult = (SimulationResult) serializer.Deserialize(reader);                

                return simuResult;
            }            

        }
        catch (Exception ex)
        {
            this.Log().LogError(ex, "Failed To DeSerialize Simulation Result" );
            return null;
        }

    }

Results in the following :

dbug: MyProject.Repositories.Mock.SimulationService_Mock[0]
      About to instantiate XmlSerializer
* Assertion at D:/a/Uno.DotnetRuntime.WebAssembly/Uno.DotnetRuntime.WebAssembly/runtime/src/mono/mono/metadata/class-setup-vtable.c:1747, condition `<disabled>' not met

* Assertion at D:/a/Uno.DotnetRuntime.WebAssembly/Uno.DotnetRuntime.WebAssembly/runtime/src/mono/mono/metadata/class-setup-vtable.c:1747, condition `<disabled>' not met

Uncaught ExitStatus ExitStatus
    --- Promise.then ---
    at _wrap_js_thenable_as_task (localhost꞉5000/package_ab280844bce8e899d33fdd5e822974e58355459b/dotnet.js:1:159808)
    at _js_to_mono_obj (localhost꞉5000/package_ab280844bce8e899d33fdd5e822974e58355459b/dotnet.js:1:172249)
    at _mono_wasm_invoke_js_with_args (localhost꞉5000/package_ab280844bce8e899d33fdd5e822974e58355459b/dotnet.js:1:203367)
    at $func219 (undefined:1:106683)
    at $func167 (undefined:1:51924)
    at $func166 (undefined:1:47591)
    at $func2810 (undefined:1:702403)
    at $func1615 (undefined:1:456456)
    at $func1619 (undefined:1:458098)
    at $mono_wasm_invoke_method (undefined:1:38572)
    at Module._mono_wasm_invoke_method (localhost꞉5000/package_ab280844bce8e899d33fdd5e822974e58355459b/dotnet.js:1:224186)
    at managed_BINDINGS_SetTaskSourceResult (mono-wasm.invalid/managed_BINDINGS_SetTaskSourceResult:17:40)
    at <anonymous> (localhost꞉5000/package_ab280844bce8e899d33fdd5e822974e58355459b/dotnet.js:1:159827)
    --- Promise.then ---
    at _wrap_js_thenable_as_task (localhost꞉5000/package_ab280844bce8e899d33fdd5e822974e58355459b/dotnet.js:1:159808)
    at _js_to_mono_obj (localhost꞉5000/package_ab280844bce8e899d33fdd5e822974e58355459b/dotnet.js:1:172249)
    at _mono_wasm_invoke_js_with_args (localhost꞉5000/package_ab280844bce8e899d33fdd5e822974e58355459b/dotnet.js:1:203367)
    at $func219 (undefined:1:106683)
    at $func167 (undefined:1:51924)
    at $func166 (undefined:1:47591)
    at $func2810 (undefined:1:702403)
    at $func1615 (undefined:1:456456)
    at $func1619 (undefined:1:458098)
    at $mono_wasm_invoke_method (undefined:1:38572)
    at Module._mono_wasm_invoke_method (localhost꞉5000/package_ab280844bce8e899d33fdd5e822974e58355459b/dotnet.js:1:224186)
    at managed__Uno_UI__Microsoft_UI_Xaml_UIElement_OnNativePointerEvent (mono-wasm.invalid/managed__Uno_UI__Microsoft_UI_Xaml_UIElement_OnNativePointerEvent:15:40)
    at dispatchPointerEvent (localhost꞉5000/package_ab280844bce8e899d33fdd5e822974e58355459b/Uno.UI.js:4485:36)
    at onPointerEventReceived (localhost꞉5000/package_ab280844bce8e899d33fdd5e822974e58355459b/Uno.UI.js:4460:36)
Failed to match method call Microsoft.WebTools.BrowserLink.LivePreview.LivePreviewBrowserUIExtensionFactory.themeChanged
The thread 0xbc7c has exited with code 0 (0x0).
The thread 0xa340 has exited with code 0 (0x0).
The thread 0x3a28 has exited with code 0 (0x0).

Workaround

No response

Works on UWP/WinUI

Yes

Environment

No response

NuGet package version(s)

<PackageReference Include="Microsoft.Extensions.DependencyInjection" Version="6.0.2-mauipre.1.22102.15" />
<PackageReference Include="Microsoft.Extensions.Logging" Version="6.0.2-mauipre.1.22102.15" />
<PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="6.0.0" />
<PackageReference Include="Microsoft.Windows.Compatibility" Version="6.0.2-mauipre.1.22102.15" />
<PackageReference Include="Newtonsoft.Json" Version="13.0.2-beta2" />
<PackageReference Include="Uno.Extensions.Logging.WebAssembly.Console" Version="1.4.0" />
<PackageReference Include="Uno.WinUI.WebAssembly" Version="4.5.12" />
<PackageReference Include="Uno.WinUI.RemoteControl" Version="4.5.12" Condition="'$(Configuration)'=='Debug'" />
<PackageReference Include="Uno.UI.Adapter.Microsoft.Extensions.Logging" Version="4.5.12" />
<PackageReference Include="Uno.Wasm.Bootstrap" Version="3.3.1" />
<PackageReference Include="Uno.Wasm.Bootstrap.DevServer" Version="3.3.1" />

Affected platforms

No response

IDE

Visual Studio 2022

IDE version

Microsoft Visual Studio Community 2022 (64-bit) - Preview Version 17.4.0 Preview 2.0

Relevant plugins

No response

Anything else we need to know?

No response

jeromelaban · 2022-10-05T20:22:35Z

jeromelaban
Oct 5, 2022
Maintainer

Thanks for the report. In general, this is related to the use of the linker, you may want to validate its configuration. Otherwise, this is a runtime issue we're unlikely to be able to fix directly, other than trying to upgrade to the latest Uno.Wasm.Bootstrap (7.0-dev) to target a more recent version of the .NET runtime.

1 reply

ToddGlodek Oct 7, 2022
Author

UPDATE : It seems like it has something to do with the DEBUGGER/DEBUG BUILD. When I try a RELEASE build, I no longer get the "Uncaught ExitStatus ExitStatus" report in the OUTPUT window - instead - I see an actual exception with a true stack trace.

As a result, I observe that XmlSerializer's behavior significantly different in WASM than it is in WinUI.

In WinUI the XmlSerializer totally ignores properties with only a getter. This is consistent with the MS documentation on XmlSerializer which says only "Public read/write properties and fields of public classes" will be serialized. On the other hand, WASM attempts so serialize the getter-only properties, but then throws an InvalidOperationException. The same seems to be the case for properties with a public getter but a private setter.
On WASM, decorating a property with the [XmlIgnore] attribute does not seem to prevent the XmlSerializer from attempting to serialize the property. On WASM, a System.InvalidOperationException: XmlSerializerUnsupportedMember exception is thrown even though the property is decorated with [XmlIgnore], but this does not happen on WinUI.

ToddGlodek · 2022-10-15T16:05:02Z

ToddGlodek
Oct 15, 2022
Author

UPDATE #2 : I have worked-around [XmlIgnore] all the all the items described above ( in UPDATE #1) and I can get it to run when using DEBUG on WASM. In DEBUG, the WinUI & WASM builds now behaves in exactly the same way.

However, when I switch to RELEASE and run using WASM, I continue to experience the InvalidOperationException when calling the XmlSerializer constructor ( e.g.XmlSerializer serializer = new(typeof(SimulationModel) ) ). Specifically, the error looks like this:

System.InvalidOperationException: XmlConstructorInaccessible, MyProject.Models.SimulationModel
   at System.Xml.Serialization.TypeDesc.CheckSupported()
   at System.Xml.Serialization.TypeScope.GetTypeDesc(Type type, MemberInfo source, Boolean directReference, Boolean throwOnError)
   at System.Xml.Serialization.TypeScope.GetTypeDesc(Type type, MemberInfo source, Boolean directReference)
   at System.Xml.Serialization.ModelScope.GetTypeModel(Type type, Boolean directReference)
   at System.Xml.Serialization.ModelScope.GetTypeModel(Type type)
   at System.Xml.Serialization.XmlReflectionImporter.ImportTypeMapping(Type type, XmlRootAttribute root, String defaultNamespace)
   at System.Xml.Serialization.XmlSerializer.GenerateXmlTypeMapping(Type type, XmlAttributeOverrides overrides, Type[] extraTypes, XmlRootAttribute root, String defaultNamespace)
   at System.Xml.Serialization.XmlSerializer..ctor(Type type, XmlAttributeOverrides overrides, Type[] extraTypes, XmlRootAttribute root, String defaultNamespace, String location)
   at System.Xml.Serialization.XmlSerializer..ctor(Type type, Type[] extraTypes)
   at MyProject.SimulationRepository_Mock.DeserializeSimModel(Stream stream)
   at MyProject.SimulationRepository_Mock.<GetSimulation>d__5.MoveNext()

When I drill into the XmlSerializer constructor's code, I observe that all the _ctor overloads have the following RequiresUnreferencedCode warning attribute. I am not sure if this is related:

      [RequiresUnreferencedCode(TrimSerializationWarning)]
      public XmlSerializer(Type type) : this(type, (string?)null)
      {
      }

I upgraded all the Uno.UI libs to v4.5.14 and the Uno.Wasm.Bootstrap libs to v7.0.0-dev.218 as detailed above.

  <PackageReference Include="Microsoft.Extensions.DependencyInjection" Version="6.0.2-mauipre.1.22102.15" />
   <PackageReference Include="Microsoft.Extensions.Logging" Version="6.0.2-mauipre.1.22102.15" />
   <PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="6.0.0" />
   <PackageReference Include="Microsoft.Windows.Compatibility" Version="6.0.2-mauipre.1.22102.15" />
   <PackageReference Include="Newtonsoft.Json" Version="13.0.2-beta2" />
   <PackageReference Include="Uno.Extensions.Logging.WebAssembly.Console" Version="1.4.0" />
   <PackageReference Include="Uno.WinUI" Version="4.5.14" />
   <PackageReference Include="Uno.WinUI.WebAssembly" Version="4.5.14" />
   <PackageReference Include="Uno.WinUI.RemoteControl" Version="4.5.14" Condition="'$(Configuration)'=='Debug'" />
   <PackageReference Include="Uno.UI.Adapter.Microsoft.Extensions.Logging" Version="4.5.14" />
   <PackageReference Include="Uno.Wasm.Bootstrap" Version="7.0.0-dev.218" />
   <PackageReference Include="Uno.Wasm.Bootstrap.DevServer" Version="7.0.0-dev.218" />

@jeromelaban - Do you have any idea why WASM would work in DEBUG but throw exceptions in RELEASE ?

1 reply

jeromelaban Oct 16, 2022
Maintainer

Yes, it's generally errors thrown when code has been removed by the linker. Make sure to validate that your assemblies are part of the linker configuration to avoid being removed.

ToddGlodek · 2022-10-17T20:08:24Z

ToddGlodek
Oct 17, 2022
Author

@jeromelaban - I dont think its the the Linker. I updated the LinkerConfig.xml file with all of the .DLLs from my projects (as you instructed) - yet, it had no effect. Plus, I was able to instantiate many of the classes from the key library even without the changes made to the LinkerConfig.xml file. However, I found that the key classes ( SimulationResult from my original post above) implements an interface which has a default interface methods. Trying to directly instantiate this class causes the "Uncaught ExitStatus ExitStatus" issue to happen.

I noticed in the Uno documentation on .NET version support that for WASM the Max .NET version is net5. I also read that :

some language features may not work properly, such as those that depend on compiler-checked types (eg array slicing, init-only properties) or on runtime support (eg default interface implementations)

So here are my questions :

Is this documentation up to date?
Is there still a potential issue with default interface methods ?
Would trying to instantiate a class with a default interface methods cause the error detailed above ?

1 reply

jeromelaban Oct 17, 2022
Maintainer

That part is indeed not up to date, we'll likely need to add the Uno version for which this is application. Still, this particular error generally is related to linking. You can try deactivating the linker altogether in release and see if this changes the behavior.

ToddGlodek · 2022-10-18T01:25:11Z

ToddGlodek
Oct 18, 2022
Author

Are we talking about this WasmShellILLinkerEnabled setting (for which FALSE is already the default setting for new projects) - or is there something different that I am totally missing ?

<PropertyGroup Condition="'$(Configuration)'=='Debug'">
  <MonoRuntimeDebuggerEnabled>true</MonoRuntimeDebuggerEnabled>
  <DefineConstants>$(DefineConstants);TRACE;DEBUG</DefineConstants>
  <DebugType>portable</DebugType>
  <DebugSymbols>true</DebugSymbols>
  <!--
  	IL Linking is disabled in Debug configuration.
  	When building in Release, see https://platform.uno/docs/articles/features/using-il-linker-webassembly.html
  	-->
  <WasmShellILLinkerEnabled>false</WasmShellILLinkerEnabled>
</PropertyGroup>

<PropertyGroup>
  <!-- TEST ONLY : Added per https://github.com/unoplatform/uno/discussions/10071-->
      WasmShellILLinkerEnabled>false</WasmShellILLinkerEnabled>
</PropertyGroup>

If its WasmShellILLinkerEnabled setting it to FALSE for both DEBUG/RELASE does not seem to have any affect.

Interesting observation

I was, however, able further troubleshoot the issue trying to instantiate the SimulationResult class (that implements an interface which uses a default interface methods). I created a slimmed-down version of the class/interface and observed that "Uncaught ExitStatus ExitStatus" is only encountered when the default method is defined inside the interface - NOT when it is defined inside a derived class.

namespace MyProject.Models;

/// <summary>
/// DEBUG ONLY : This is a vastly simplified mock-up of the SimulationResult class used to isolate the conditions 
/// which causes the "Uncaught ExitStatus ExitStatus" issue.  The MOCK/SAMPLE values are for illustration only.
/// </summary>
public interface IMockInterface<D, R> : IDomainBounds<D>, IRangeBounds<R>, IEquatable<IDomainRangeBounds<D, R>>
    where D : IComparable
    where R : IComparable
{
    /****************************************************************************************************************
     *  The "Uncaught ExitStatus ExitStatus" issue occurs when this method is uncommented, and Equals() is invoked  *
     *  as a default interface method.   However, if the Equals() method is moved to the derrived class, then the   *
     *  "Uncaught ExitStatus ExitStatus" issue is not observed & all test cases are performed successfully          *
     ****************************************************************************************************************/
    //bool IEquatable<IDomainRangeBounds<D, R>>.Equals(IDomainRangeBounds<D, R> other)
    //{
    //    return Equals((other as IDomainBounds<D>)) && Equals(other as IRangeBounds<R>);
    //}

}


/// <summary>
/// DEBUG ONLY : This is a vastly simplified mock-up of the SimulationResult class used to isolate the conditions 
/// which causes the "Uncaught ExitStatus ExitStatus" issue.  The MOCK/SAMPLE values are for illustration only.
/// </summary>
public class SimulationResult_TEST : SimulationResult_Core, IMockInterface<DateOnly, double>
{
    public DateOnly MinDomain {
        get {
            return DateOnly.MinValue;
        }
    }

    public DateOnly MaxDomain {
        get {
            return DateOnly.MaxValue;
        }
    }

    public double MinRange {
        get {
            return double.MinValue;
        }
    }

    public double MaxRange {
        get {
            return double.MaxValue;
        }
    }

    /****************************************************************************************************************
     *  SEE COMMENT ABOVE REGARDING Equals() used as a default interface method                                     *
     ****************************************************************************************************************/
    public bool Equals(IDomainRangeBounds<DateOnly, double> other)
    {
        return MinDomain.Equals(MaxDomain) && MinRange.Equals(MaxRange);
    }

}

2 replies

jeromelaban Oct 18, 2022
Maintainer

Thanks for the update. This definitely seems like a runtime bug then. You may want to try and see if the latest bootstrapper fixes the issue (7.0.0-dev.xx), otherwise this will be an issue to open on the dotnet/runtime repository.

jeromelaban Oct 19, 2022
Maintainer

(following #10071 (comment)) This is an unrelated error, which likely means that the issue has not been fixed in the runtime.

ToddGlodek · 2022-10-19T20:25:03Z

ToddGlodek
Oct 19, 2022
Author

Using Bootstrapper (version="7.0.0-dev.218") I still see the "Uncaught ExitStatus ExitStatus" message, but now there is a new "mono_wasm_stringify" bit at the top.

    at mono_wasm_stringify_as_error_with_stack (http://localhost:5000/package_1db474e7836c7bb6bf5ce1707752b48304b0bc5e/dotnet.js:5:620)
    at Object.mono_wasm_trace_logger (http://localhost:5000/package_1db474e7836c7bb6bf5ce1707752b48304b0bc5e/dotnet.js:5:985)
    at _mono_wasm_trace_logger (http://localhost:5000/package_1db474e7836c7bb6bf5ce1707752b48304b0bc5e/dotnet.js:14:111110)
    at http://localhost:5000/package_1db474e7836c7bb6bf5ce1707752b48304b0bc5e/dotnet.wasm:wasm-function[108]:0x9f12
    at http://localhost:5000/package_1db474e7836c7bb6bf5ce1707752b48304b0bc5e/dotnet.wasm:wasm-function[2700]:0xab96b
    at http://localhost:5000/package_1db474e7836c7bb6bf5ce1707752b48304b0bc5e/dotnet.wasm:wasm-function[8609]:0x1c87d0
    at http://localhost:5000/package_1db474e7836c7bb6bf5ce1707752b48304b0bc5e/dotnet.wasm:wasm-function[8611]:0x1c882f
    at http://localhost:5000/package_1db474e7836c7bb6bf5ce1707752b48304b0bc5e/dotnet.wasm:wasm-function[8612]:0x1c8863
    at http://localhost:5000/package_1db474e7836c7bb6bf5ce1707752b48304b0bc5e/dotnet.wasm:wasm-function[2978]:0xb6318
    at http://localhost:5000/package_1db474e7836c7bb6bf5ce1707752b48304b0bc5e/dotnet.wasm:wasm-function[2573]:0xa3e39


Uncaught ExitStatus ExitStatus
    at quit_ (localhost꞉5000/package_1db474e7836c7bb6bf5ce1707752b48304b0bc5e/dotnet.js:14:1373)
    at procExit (localhost꞉5000/package_1db474e7836c7bb6bf5ce1707752b48304b0bc5e/dotnet.js:14:149589)
    at exit (localhost꞉5000/package_1db474e7836c7bb6bf5ce1707752b48304b0bc5e/dotnet.js:14:149454)
    at _exit (localhost꞉5000/package_1db474e7836c7bb6bf5ce1707752b48304b0bc5e/dotnet.js:14:104800)
    at $func108 (localhost꞉5000/package_1db474e7836c7bb6bf5ce1707752b48304b0bc5e/dotnet.wasm:1:40731)
    at $func2700 (localhost꞉5000/package_1db474e7836c7bb6bf5ce1707752b48304b0bc5e/dotnet.wasm:1:702828)
    at $func8609 (localhost꞉5000/package_1db474e7836c7bb6bf5ce1707752b48304b0bc5e/dotnet.wasm:1:1869777)

0 replies

ToddGlodek · 2022-10-20T04:47:02Z

ToddGlodek
Oct 20, 2022
Author

Created [WASM] "Uncaught ExitStatus ExitStatus" is encountered when a default method is defined inside the interface - NOT when it is defined inside a derived class. #77244

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

"Uncaught ExitStatus ExitStatus" Encountered Instantiating New XmlSerializer() [WASM] #10071

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 6 comments 5 replies

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

"Uncaught ExitStatus ExitStatus" Encountered Instantiating New XmlSerializer() [WASM] #10071

ToddGlodek Oct 5, 2022

Current behavior

Expected behavior

How to reproduce it (as minimally and precisely as possible)

Workaround

Works on UWP/WinUI

Environment

NuGet package version(s)

Affected platforms

IDE

IDE version

Relevant plugins

Anything else we need to know?

Replies: 6 comments · 5 replies

jeromelaban Oct 5, 2022 Maintainer

ToddGlodek Oct 7, 2022 Author

ToddGlodek Oct 15, 2022 Author

jeromelaban Oct 16, 2022 Maintainer

ToddGlodek Oct 17, 2022 Author

jeromelaban Oct 17, 2022 Maintainer

ToddGlodek Oct 18, 2022 Author

Interesting observation

jeromelaban Oct 18, 2022 Maintainer

jeromelaban Oct 19, 2022 Maintainer

ToddGlodek Oct 19, 2022 Author

ToddGlodek Oct 20, 2022 Author

ToddGlodek
Oct 5, 2022

Replies: 6 comments 5 replies

jeromelaban
Oct 5, 2022
Maintainer

ToddGlodek Oct 7, 2022
Author

ToddGlodek
Oct 15, 2022
Author

jeromelaban Oct 16, 2022
Maintainer

ToddGlodek
Oct 17, 2022
Author

jeromelaban Oct 17, 2022
Maintainer

ToddGlodek
Oct 18, 2022
Author

jeromelaban Oct 18, 2022
Maintainer

jeromelaban Oct 19, 2022
Maintainer

ToddGlodek
Oct 19, 2022
Author

ToddGlodek
Oct 20, 2022
Author