Obiekty Delphi, obiekty NIL i interfejsy

Question

Szukam wskazówek, jak debugować awarię w aplikacji, która używa obwolut XML XML w Delphi VCL. Podejrzewam, że zepsuło się pamięć lub jakieś niejasne zło dzieje się między obiektami i interfejsami, takie jak błędy liczące odniesienia lub korupcja sterty. Pytanie brzmi: w jaki sposób mogę debugować taką awarię?

Ten konkretny kod intensywnie wykorzystuje wewnętrzne interfejsy XmlIntf (IXMLNode) i rozszerza je. ISomethingCustom to interfejs, który rozszerza IXMLNode. Problem pojawia się tam, gdzie zawieszamy się gdzieś w funkcji rekurencyjnej, która jest przekazywana przez ISomethingCustom, który jest również (lub obsługuje również, w kategoriach interfejsu) IXMLNode.

boolean UtilityFunction(aNode: ISomethingCustom):Boolean; 
    begin 
     if not Assigned(aNode) then exit; // this works. great. 
     if not Assigned(aNode.ParentNode) then exit; // this DOES NOT WORK. 
    // code that blows up if aNode.ParentNode is not assigned. 
    end; 

Sytuacja jest taka, że ​​anoda jest również IXMLNode, a wartość IXMLNode.ParentNode jest przypisany (nie zero), a mimo to wskazuje na obiekt COM, które mogły zostać uwolniony, zniszczony lub uszkodzony w jakiś sposób. Próbuję dowiedzieć się, CO dzieje się, gdy wskaźnik interfejsu może wydawać się poprawny, ale obiekt za nim został nuked jakoś.

Sprawdzanie określony cel (aNode.ParentNode) zwraca TRUE, nawet jeśli były do ​​próby oddanych w debugger (tylko w czasie wykonywania, a nie w kodzie), podobnie jak to:

1. skontrolować/oceny anoda
2. sprawdzić/ocenić TInterfacedObject (anoda) .nazwaklasy (prac w Delphi 2010, co najmniej!)
3. teraz rzucać TWhateverClassNameYouGotBefore (anoda).
4. W debugerze widzę teraz, że jest to NIL. Co może oznaczać, że magiczny "interfejs rzutowania z powrotem do obiektu" cecha, która jest nowa w delphi 2010, nie działa.

Wierzę, że próbuję debugować problem, w którym hałdy są uszkodzone, lub obiekty COM są uszkodzone na stercie, z powodu problemu z licznikiem odniesień.

Naprawdę myślę, że nikt nigdy nie powinien mieć sytuacji, w której interfejs wydaje się prawidłowy, ale obiekt pod spodem został usunięty. Naprawdę chciałbym wiedzieć, co robić i co się dzieje.

Answer 1

Chociaż nie wykazano go w kodzie, twój komentarze wydają się wskazywać, że odrzucasz zmienną interfejsu do typu klasy. To nie jest dozwolone. Opisałem dlaczego:

• Why can’t I cast an interface reference to an object reference?

referencje interfejsu i obiekt odniesienia nie wskazują na te same rzeczy. Dlatego wywołanie metody na jednym, gdy kompilator myśli, że masz drugą, przyniesie nieoczekiwane wyniki. Miałeś pecha, ponieważ kod nadal działał, zamiast awaryjnie naruszać prawa dostępu, co oznaczałoby, że robiłeś coś złego.

Powyższy artykuł kończy się sugerowaniem, że używasz funkcji JclSysUtils​.GetImplementorOfInterface z JCL, jeśli masz interfejs implementowany przez Delphi i interfejs nie oferuje własnej funkcji do ujawnienia obiektu leżącego pod spodem.

Answer 2

Dzikie przypuszczenie: Czy próbowali umieścić aNode.ParentNode w zmiennej lokalnej i używać go w pozostałej części Utilityfunction:

function UtilityFunction(aNode: ISomethingCustom): Boolean; 
    var 
    lParentNode: INode; 
    begin 
     if not Assigned(aNode) then exit; // this works. great. 
     lParentNode := aNode.ParentNode; 
     if not Assigned(lParentNode) then exit; 
    // code that uses lParentNode. 
    end; 

Answer 3

Moja sugestia polega na upewnieniu się, że funkcja ParentNode jest rzeczywiście wywoływana w Assigned(aNode.ParentNode). W Delphi istnieją pewne nieprzyjemne przypadki narożnikowe, w których procedura/funkcja bez argumentów nie jest wywoływana, ale raczej odwołanie jest brane gdy pominięto nawias.

Spróbuj zmienić na Assigned(Anode.ParentNode()) (który powinien mieć taki sam efekt, jak sugestia François).