[Mono-dev] Mono 2.4 crashes due to accessing freed data structures

[Rodrigo Kumpera]

On Fri, May 29, 2009 at 5:14 PM, Ulrich Weigand <uweigand at de.ibm.com> wrote:

> Hello,
>
> diff -urNp mono-2.4-orig/mono/metadata/metadata.c
> mono-2.4/mono/metadata/metadata.c
> --- mono-2.4-orig/mono/metadata/metadata.c      2009-02-14
> 00:33:05.000000000 +0100
> +++ mono-2.4/mono/metadata/metadata.c   2009-05-28 20:12:38.000000000 +0200
> @@ -2196,7 +2197,8 @@ inflated_method_in_image (gpointer key,
>        // https://bugzilla.novell.com/show_bug.cgi?id=458168
>        return method->declaring->klass->image == image ||
>                (method->context.class_inst && ginst_in_image
> (method->context.class_inst, image)) ||
> -               (method->context.method_inst && ginst_in_image
> (method->context.method_inst, image)) || signature_in_image
> (mono_method_signature ((MonoMethod*)method), image);
> +               (method->context.method_inst && ginst_in_image
> (method->context.method_inst, image)) ||
> +               (((MonoMethod*)method)->signature && signature_in_image
> (((MonoMethod*)method)->signature, image));
>  }
>
>  static gboolean
>
>
This has been fixed in trunk and 2.4



>
> The second problem is related to wrapper classes allocated by the
> routines in marshal.c.  I've been seeing various instances of crashes
> caused by those routines returning apparently clobbered method structures.
>
> It turns out this was caused by stale entried in the caches maintained
> by the marshal.c routines.  For example, the
> MonoMethod *mono_marshal_get_static_rgctx_invoke (MonoMethod *method)
> routine will store the MonoMethod structure describing the wrapper for
> "method" into a cache allocated on the mempool associated with the
> image related to the method's class.  For "normal" methods, the method
> structure itself was already allocated on that same mempool, so the
> wrapper has identical lifetime as the method it wraps.
>
> However, there is one case where things are more complex: "inflated"
> generic methods.  These are *not* allocated on a mempool, but on the
> heap, and will be freed at a certain point in time.  However, nothing
> ensures that any previously allocated wrapper for such a method is
> also freed at this time.
>
> For the most part, this does not matter much, as the wrapper cache is
> indexed using the address of the MonoMethod structure as key.  If the
> method no longer exists, it isn't looked up, so it doesn't matter that
> a stale value is still in the hash table.
>
> However, it *can* happen that a later allocation of a fresh MonoMethod
> just happens to reside at the same address as a method that was deleted
> previously.  Now, when looking up a wrapper for the new method, the
> stale entry for the old method may indeed be found.  This causes various
> problems; in particular, while the cached wrapper method itself is still
> live, some of the structures it points to (type, signature) may themselves
> have been deleted in the meantime, so random memory may be accessed.
>
> A similar problem seems to occur for dynamic methods, and for those it
> seems special care is taken to remove wrappers for such methods from the
> cache when the method is deleted (mono_marshal_free_dynamic_wrappers).
>
> It looks like a similar approach ought to be taken for inflated methods.
> The following patch implements this.  Again, I'm not complete sure this
> is the right approach, but it fixes the symptoms for me.
>

Your change isn't required because you only remove from image hash tables,
which are released together with the inflated method.

Can you try OpenSim using mono from the tip of the 2.4 branch?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090529/87953307/attachment.html