Obtenir l'Adresse Mémoire de l' .NET Objet (C#)

Je suis en train de traquer un bug dans le mono d'exécution lorsqu'une variable semble être attribuée à un objet valide, puis attribué plus tard à un faux objet, plus précisément 

//early in code I allocate, fine
var o = new object(); //valid allocation
//later in code this is called, not fine
lock(o) //<- is triggering bug due to "o" now referencing a nonsense memory location.

Je voudrais savoir quand la référence à "o" devient non-sens, et pour ce faire je suis à la recherche d'un moyen de déterminer l'adresse de "o" à divers intervalles dans le code C#. Je sais, c'est similaire à d'autres questions avec des réponses "ne fais pas ça il y a une table", mais le GC ne fonctionne pas donc j'ai besoin d'une solution de contournement.

Personne ne sait comment je peux déterminer l'adresse d'un mono objet en C#? Suis bien le lien dans le code non managé ou quoi que ce soit. (Toutes les autres indices moyens de diagnostiquer le problème principal apprécié pour).

  • Quel est le message d'erreur exact? Est-il à propos de l'éliminer plutôt que "d'être non-sens"?
  • Au lieu de verrouillage sur un object, pourriez-vous créer une classe jetables avec un finaliseur-mais pas de ressources réelles -- puis la verrouiller, et de définir les pauses dans le débogueur quand il est finalisé?
  • L'erreur complet est décrit ici, et qui se passe en aval: bugzilla.xamarin.com/show_bug.cgi?id=21939 Fondamentalement, le GC traite une mauvaise référence comme un objet, conduisant à un sigsegv
  • Est-ce que tout dans la même méthode?
  • malheureusement, le code est dans la classe runtime des bibliothèques (en particulier Paresseux.cs), donc je suis en train de corriger le bogue, plutôt que de changer le bon C#
  • l'objet de l'allocation est dans le constructeur, le verrou est pris, plus en aval dans une méthode. Lignes 87 et 150 dans ce fichier (github.com/mono/mono/blob/master/mcs/class/corlib/System/...)
  • C'est un undebuggable problème, l'adresse d'un objet change constamment, tandis que le GC compacte le tas. Vous avez besoin de poursuivre le type de bug, vous pouvez le fixer et à supposer que cela est causé par la corruption de segment. Le genre produit par débordement de mémoire tampon dans le code non managé.
  • plus difficile bug que j'ai vu jusqu'à présent et semble certainement en raison d'une corruption de mémoire. Si l'adresse change à chaque GC, il semble que lorsque la modification de la mauvaise valeur, il est toujours affecté à l'exact même mauvais (et faux) de la valeur, je suis donc vérifier si c'est le cas. Mon espoir était de restreindre l'intervalle lorsque la corruption se produit en le faisant. Si vous savez de quoi que ce soit d'autre qui est utile pour le débogage mem corruption, serait heureux de l'entendre.

InformationsquelleAutor evolvedmicrobe | 2014-08-20
  1. 12

    Vous devriez être en mesure d'utiliser le GCHandle construire pour accomplir cette tâche.

    GCHandle objHandle = GCHandle.Alloc(obj,GCHandleType.WeakTrackResurrection);
int address = GCHandle.ToIntPtr(objHandle).ToInt32();

    Où 'obj' est l'objet dont l'adresse vous essayez d'obtenir.

    • Merci, je l'ai essayé et il semble que le "Adresse" ne correspond pas à une adresse physique, mais il le fait à travers le temps. Je cueille, c'est juste la représentation interne de l'objet.
    • Le "adresse" de l'int doit correspondre à l'actuelle pointeur dans la mémoire, qui peuvent changer en raison de la norme interne de gestion de la mémoire par le GC. Si vous avez besoin d'une adresse fixe, vous devez vous assurer qu'il est un objet déformé dans la mémoire et l'utilisation de 'GCHandle.AddrOfPinnedObject(objHandle); " au lieu de GCHandle.ToIntPtr(objHandle);. Gardez à l'esprit, le GCHandle.Fonction Alloc() permet de s'assurer que l'objet n'est pas nettoyée de la mémoire interne, de la gestion de la mémoire, de sorte que vous devrez manuellement désallouer de la mémoire quand il n'est plus nécessaire pour éviter les fuites.
    • Je crois que le GCHandle.ToIntPtr pointe vers l'adresse de la poignée, et non pas de l'objet
    • Ouais, il sera fait à l'entier de la GCHandle objet lui-même. C'était un oubli de ma part. Cependant, la AddrOfPinndedObject sera de retour l'adresse de l'objet lui-même (qui, rappelons-le, doit être épinglé dans la mémoire ainsi que son adresse n'est pas modifiée par la mémoire interne de gestion). Qui devrait fournir ce que vous travaillez pour.
    • Malheureusement, en essayant d'obtenir le handle conduit à ObjectContains non-primitif ou non blittable de données
    InformationsquelleAutor s.burns
  2. 5

    S'avère que ce n'est pas possible .NET directement, mais peut être accompli en modifiant le mono d'exécution de code. Pour créer une méthode C# qui permet de lire l'adresse de la mémoire, apporter les modifications suivantes à la source mono code:

    Modifier gc-interne.h pour ajouter

    gpointer    ves_icall_System_GCHandle_GetAddrOfObject (MonoObject *obj) MONO_INTERNAL;

    Modifier gc.c ajouter:

    gpointer    ves_icall_System_GCHandle_GetAddrOfObject (MonoObject *obj) {
    return (char*)obj;
}

    Modifier GCHandle.cs d'ajouter:

    MethodImplAttribute(MethodImplOptions.InternalCall)]
private extern static IntPtr GetAddrOfObject(object obj);

public static IntPtr AddrOfObject(object o)
{
    IntPtr res = GetAddrOfObject(o);
    return res;
}

    Modifier icall-def.h pour ajouter

    ICALL(GCH_6, "GetAddrOfObject", ves_icall_System_GCHandle_GetAddrOfObject)

    Noter que ceux-ci doivent être dans l'ordre, donc de l'ajouter au-dessus de la GetAddrOfPinnedObject ligne
    Reconstruire

    Enfin, l'appeler à partir de C#

    for (int i = 0; i < 100; i++) {
    object o = new object ();
    var ptr = GCHandle.AddrOfObject (o);
    Console.WriteLine ("Address: " + ptr.ToInt64().ToString ("x"));
}
    InformationsquelleAutor evolvedmicrobe
  3. 1

    Vous ne pouvez pas obtenir l'adresse d'un manged objet en code managé, en général. Si l'objet a un champ comme un int, tu pourrais prendre d'adresse avec le fixe C#, instruction et alors vous auriez un pointeur à l'intérieur de l'objet. À des fins de débogage, vous pourriez faire quelques hypothèses et obtenir le décalage de la base de pointeur de l'objet (sur 32 bits plates-formes de l'objet taille d'en-tête sur la mono est de 8 octets 16 octets sur les architectures 64 bits, en ce moment).

    Votre rapport de bogue déclare que vous êtes à l'aide de l'Boehm collector, bien que, et que collectionneur de ne pas déplacer les objets en mémoire, le bug pourrait être causé par certains indépendants de corruption de la mémoire, par l'objet à tort libéré ou d'une autre logique bug dans le GC (je ne suis pas sûr de la taille zéro vous l'avez souligné est importante, puisqu'un objet géré est au moins de 8 à 16 octets d'en-tête).

    • Merci, connaissez-vous une méthode pour obtenir l'adresse dans le code non managé (peut-être une méthode que je pourrais ajouter à la source mono)? Sachant que le collecteur n'est pas de déplacer des objets est très utile. J'aime l'idée d'utiliser un type simple avec un int, mais malheureusement, l'erreur disparaît lorsqu'un type autre que l'objet est utilisé. Il ne semble pas être dû à une corruption de la mémoire et de la size_zero_object n'est pertinente que la mémoire est toujours écrite avec cette valeur, si elle ne semble pas être affecté que la valeur à l'origine.
    InformationsquelleAutor lupus
  4. 0

    Ma alternatives... Aussi @ Cette question similaire

    #region AddressOf
///<summary>
///Provides the current address of the given object.
///</summary>
///<param name="obj"></param>
///<returns></returns>
[System.Runtime.CompilerServices.MethodImpl(System.Runtime.CompilerServices.MethodImplOptions.AggressiveInlining)]
public static System.IntPtr AddressOf(object obj)
{
if (obj == null) return System.IntPtr.Zero;
System.TypedReference reference = __makeref(obj);
System.TypedReference* pRef = &reference;
return (System.IntPtr)pRef; //(&pRef)
}
///<summary>
///Provides the current address of the given element
///</summary>
///<typeparam name="T"></typeparam>
///<param name="t"></param>
///<returns></returns>
[System.Runtime.CompilerServices.MethodImpl(System.Runtime.CompilerServices.MethodImplOptions.AggressiveInlining)]
public static System.IntPtr AddressOf<T>(T t)
//refember ReferenceTypes are references to the CLRHeader
//where TOriginal : struct
{
System.TypedReference reference = __makeref(t);
return *(System.IntPtr*)(&reference);
}
[System.Runtime.CompilerServices.MethodImpl(System.Runtime.CompilerServices.MethodImplOptions.AggressiveInlining)]
static System.IntPtr AddressOfRef<T>(ref T t)
//refember ReferenceTypes are references to the CLRHeader
//where TOriginal : struct
{
System.TypedReference reference = __makeref(t);
System.TypedReference* pRef = &reference;
return (System.IntPtr)pRef; //(&pRef)
}
///<summary>
///Returns the unmanaged address of the given array.
///</summary>
///<param name="array"></param>
///<returns><see cref="IntPtr.Zero"/> if null, otherwise the address of the array</returns>
[System.Runtime.CompilerServices.MethodImpl(System.Runtime.CompilerServices.MethodImplOptions.AggressiveInlining)]
public static System.IntPtr AddressOfByteArray(byte[] array)
{
if (array == null) return System.IntPtr.Zero;
fixed (byte* ptr = array)
return (System.IntPtr)(ptr - 2 * sizeof(void*)); //Todo staticaly determine size of void?
}
#endregion
    InformationsquelleAutor Jay