Ninject - Binding.GetProvider löst NullReferenceException aus

8

Ich verwende Version 2.2.0.0 von Ninject in einer asp.net-Webformularanwendung und nach ein paar hundert Anfragen wird manchmal eine NullReferenceException in der GetProvider-Methode der Binding-Klasse ausgelöst.

Beispiel für einen Stack-Trace: Ссылка

Die Ausnahme tritt nur auf, wenn ich die Anwendung stresst und der Ursprung der Ausnahme normalerweise anders ist (Auflösung bestimmter Schnittstellen).

Um zu verstehen, warum dieses Problem aufgetreten ist, habe ich mir den Ninject-Quellcode angeschaut und einige Codezeilen zu Debuggingzwecken eingefügt. Ich habe später bestätigt, dass das Objekt, das NULL ist, die ProviderCallback-Eigenschaft in der Binding-Klasse ist.

Ich habe auch Code in den set-Operator der ProviderCallback-Eigenschaft geschrieben, um zu verstehen, ob er auf null gesetzt wurde. Nach einigen Tests und einigen Speicherabbildern scheint die ProviderCallback-Eigenschaft nicht auf einen Nullwert gesetzt zu sein. Daher denke ich, dass die Instanz von GC erfasst wird.

Ich verstehe immer noch nicht, warum das passiert ...

Jede Hilfe wird sehr geschätzt.

Bearbeiten: Wir haben auf die neueste Version von Ninject aktualisiert, nur um zu überprüfen, ob die Ausnahme weiterhin auftritt, aber wir haben die gleiche Ausnahme nach dem Stresstest der Anwendung: Ссылка

    
Tiago M 20.11.2012, 14:51
quelle

1 Antwort

1

Ich kann Ihnen den Grund für dieses Problem nicht nennen, da ich ein solches Verhalten nicht reproduzieren kann. Aber hier sind einige Schritte, die Sie ergreifen können, um das Problem zu identifizieren.

Wie Sie sagen, wird das Problem von ProviderCallback verursacht, das ist null . Dies kann nicht durch GC verursacht werden, da GC niemals null einer Eigenschaft zuweist. Stattdessen erhalten Sie eine bereits vereinbarte Ausnahme oder andere seltsame Verhaltensweisen. Aber es gibt noch andere Gründe, warum dies passieren kann:

  1. Null wird zu einem bestimmten Zeitpunkt zugewiesen, aber da Sie dies bereits verifiziert haben, ist das nicht der Grund.
  2. Es wurde nie zugewiesen.
  3. Ein neuer BindingConfiguration wird zu einem späteren Zeitpunkt erstellt.

Der dritte Punkt kann leicht verifiziert werden, indem im Konstruktor BindingConfiguration ein Haltepunkt hinzugefügt wird. Es sollte nicht mehr aufgerufen werden, nachdem der Kernel erfolgreich konfiguriert wurde und Sie beginnen, Objekte aufzulösen.

Für das zweite Problem führe folgendes nach der Kernel-Konfiguration aus:

%Vor%     
Remo Gloor 20.11.2012 18:07
quelle