Safety check for "diamond dependencies" on netmodules

Safety check for "diamond dependencies" on netmodules

This is something I noticed while following up on an issue with
mcs/tests/test-418.exe. The ECMA-335 spec contains the text:

    "Usually, a module belongs only to one assembly, but it is
possible to share it across assemblies. When assembly A is loaded at
runtime, an instance of M3 will be loaded for it. When assembly B is
loaded into the same application domain, possibly simultaneously with
assembly A, M3 will be shared for both assemblies. Both assemblies
also reference F2, for which similar rules apply."

What happens in Mono when two assemblies both load the same module? We
never planned for that possibility in our architecture. Looking at our
current code, when an assembly image loads a module image into its
modules[] or files[] array, it immediately sets the "assembly" field
of that module to its own MonoAssembly. This field is a plain C
pointer with no safety on it whatsoever, and is references in various
places including by icalls. Consider the following scenario:

- Assembly A is loaded, references module M3, sets M3->assembly to
  A->assembly.
- Assembly B is loaded, references module M3, sets M3->assembly to
  b->assembly.
- Assembly B is unloaded.

At this point the image for B is unloaded, but M3 is still alive
because A keeps it alive, and its image contains a C pointer to freed
memory. There is likely some way to trigger a crash from this point.

Because the above scenario is fairly exotic, I dealt with it by just
causing the module loader to detect when multiple assemblies are
referencing the same module and throwing an exception in this case. I
also added a test to verify the exception is thrown. Allowing the
module load to raise an exception required adding _checked versions of
several functions.