Problem with loading assemblies

[MateuszKlatecki]

Target name(s)

ALL

Firmware version

No response

Was working before? On which version?

No response

Device capabilities

No response

Description

In the nanoframework, we can load an assembly using the System.Reflection.Assembly.Load(byte[] rawAssembly) method. We have noticed that sometimes this fails for no apparent reason. After analysis, it turned out that the problem occurs only for assemblies that require a static constructor thread to run.
In general, the whole mechanism works like this:

1. Calculation and setting the timeout to 40ms
2. Create a static constructor thread
3. Exiting the method and waiting for timeout.
4. Since the constructors thread has the highest priority, only it will be executed, after which the scheduler will find that there has been a timeout and will enter the load method again, where it will find that the assembly has been loaded and everything works as it should.

This is a happy path. However, it turns out that creating a static constructor thread allocates memory, and it may happen that it is necessary to run the Garbage Collector. It can takes a lot of time and when we get to WaitEvents, the timeout is over and the partially loaded assembly is destroyed. Unfortunately, the constructor thread is already created and after exiting the load method, it starts to be executed and then various strange things happen with HardFaults at the forefront :)

How to reproduce

No response

Expected behaviour

No response

Screenshots

No response

Aditional information

No response

[josesimoes]

@MateuszKlatecki thanks for the detailed bug and the thorough investigation you've done. That will be very helpfull when working on this.
I totally get the issue and I understand what you've described. More work ahead! 😅

BTW, it's great that you guys are finding these edge cases. It sure contributes to have a better execution engine for nanoFramework!

[vtelenak]

Thank you for this post. My library used the code:

private static ushort[] CrcTable = { 0X0000, 0XC0C1, .... };

And AssemblyLoad.Load crashed. It was enough to modify the code so that the CrcTable is filled only when the program is running, and the problem is solved.
However, this is another non-intuitive flaw in NF that pretty much disqualifies it for real-world use. Too bad it hasn't been repaired even after a year.

[Ellerbach]

@vtelenak nanoFrameworj is community based and open source. If you have a fix, feel free to submit a PR! Thanks!

[josesimoes]

@vtelenak sorry to hear that this issue that (according to the feedback here) seems to affect 2 users, "disqualifies it for real-world use"... We prioritize work on issues that have the most widespread impact or are critial.

As Laurant mentioned, this is a community-based project. There 2 companies providing financial support to it, that doesn't pay for a full-time developer. Doing our best, but I recognize it is not perfect and, sometimes, things seem to take too long to fix...

If you have fix, by all means, go for a PR. If you are a commercial user or need this fixed asap, please consider supporting the required work and it will be investigated and fixed. 😃