Zugriffsverletzung beim TObjectDictionary.Add

[haentschman]

Bitteschön...

Delphi-Quellcode:

FRoleRightDict := TUserRoleRightDict.Create; // Dict ohne Freigabe (sortierte Liste RoleRightList)
FRoleRightList := TUserRoleRightList.Create; // List gibt Objekte frei
...
FRoleRightDict := TUserRoleRightDict.Create([doOwnsValues]); // gleicher Fehler
FRoleRightList := TUserRoleRightList.Create(False);

Wer meinen dusslichen Fehler findet...dem gebe ich ein aus...

Nachtrag: FComparer ist nil.

[Stevie]

- Stoppunkt nach dem Create und schauen, ob FRoleRightDict.FComparer assigned ist.
- Schauen, ob es nicht aus Versehen irgendwo freigegeben wird bevor der Add Aufruf passiert.

P.S. Ich glaub, ich mach mal für die Forentage 2020 einen "Fehleranalyse 101" Vortrag

[haentschman]

Zitat:

Ich glaub, ich mach mal für die Forentage 2020 einen "Fehleranalyse 101" Vortrag

...Danke für die aufbauenden Worte. Kannst du dir vorstellen, daß ich für das Debuggen von "Bibliotheken" keinen Nerv/Zeit habe?

Ich verwende Dictionaries ständig. Einen Comparer habe ich noch nie benutzt. Ich erstelle die Instanz wie immer meistens mit [doOwnsValues].

Danke...

Nachtrag:

* Nach dem Create ist der Comparer Assigned (Pointer($3BFEF6C) as {System.Generics.Defaults}IEqualityComparer<System .Integer>)
* vor dem Add ist der Comparer Assigned (nil)
-> dazwischen passiert mit dem Dict nix. Das Dict wird erzeugt und dann beschrieben.

Eine Idee habe ich noch...aber erst morgen früh.

[Stevie]

Zitat von haentschman:

Zitat:

Ich glaub, ich mach mal für die Forentage 2020 einen "Fehleranalyse 101" Vortrag

...Danke für die aufbauenden Worte. Kannst du dir vorstellen, daß ich für das Debuggen von "Bibliotheken" keinen Nerv/Zeit habe?

Ich verwende Dictionaries ständig. Einen Comparer habe ich noch nie benutzt. Ich erstelle die Instanz wie immer meistens mit [doOwnsValues].

Danke...

Hilfe zu leisten kostet natürlich keine Zeit...

Es geht nur darum, dass wenn bestimmte grundlegenden Dinge schon vorab passiert sind (und das ist nun keineswegs nur auf dich und diesen Fall bezogen) man entweder schon selbst drauf kommt oder es anderen erleichtert, Hilfe zu leisten. Das ist glaube ich, im Interesse aller.

Ist wie mit dem Fisch geben oder Angeln beibringen. Klar, wenn man keine Lust oder Zeit auf Angeln hat, kann man auch andere nach nem Fisch fragen (oder man kauft ihn im Supermarkt)

Punkt ist, dass man keinen comparer angeben muss, der wird intern gebaut/bezogen. Wenn der also plötzlich nil ist, kann es sich nur um Vorzeitiges Freigeben des Dictionaries handeln oder was ich eher für unwahrscheinlich halte Speicherüberschreiben dieses Objekts durch eine andere Stelle.

[Der schöne Günther]

Und was ist "TSEAMUserRoleRightDict"? Ist das immer noch ein Alias? Oder eine eigene Unterklasse welche z.B. nur "inherited" oder "inherited Create" im Konstruktor sagt?

Ein Codeschnippsel zum Nachstellen wäre echt super-hilfreich.

[haentschman]

TSEAMUserRoleRightDict war ein Tippfehler.
Korrekt wäre wie in den Codeschnippseln TUserRoleRightDict.

Danke...

[haentschman]

Moin...

Zitat:

Eine Idee habe ich noch...aber erst morgen früh.

...Fazit: Eine Objektkopie mit Marshal/UnMarshal nimmt den Comparer nicht mit.

Danke für eure Hilfe.

[generic]

Zitat von haentschman:

Bitteschön...
FRoleRightDict := TUserRoleRightDict.Create([doOwnsValues]); // gleicher Fehler

Wenn ich mir die Exception und den Stacktrace anschaue, dann glaube ich eher das es am KEY liegt.
Ähnlich wie bei den Values, kann auch der KEY owned werden.

[haentschman]

Zitat:

Wenn ich mir die Exception und den Stacktrace anschaue, dann glaube ich eher das es am KEY liegt.

Dem widerspricht die fast tägliche Benutzung / Implementierung eines Dictionaries. Die diesem Falle war aber eine Objektkopie des Datenobjektes mit enthaltenem Dictionary verantwortlich. Mit der Kopie ist der FComparer intern nicht instanziert worden.

Danke...

[Uwe Raabe]

Zitat von haentschman:

diesem Falle war aber eine Objektkopie des Datenobjektes mit enthaltenem Dictionary verantwortlich. Mit der Kopie ist der FComparer intern nicht instanziert worden.

Das liegt vermutlich daran, daß nicht der gewünschte Construktor von TDictionary aufgerufen wurde, sondern der von TObject, weil UnMarshal nach einem parameterlosen Constructor sucht. Und Interface-Felder werden offenbar nicht serialisiert.