Laden...

Merkwürdige allokation von Arrays

Erstellt von DavidT vor 13 Jahren Letzter Beitrag vor 13 Jahren 1.359 Views
DavidT Themenstarter:in
998 Beiträge seit 2007
vor 13 Jahren
Merkwürdige allokation von Arrays

Hallo,

ich entwickle im Moment ein Framework zur Bildverarbeitung mit .NET. Dabei allokiere ich ein 3-Dimensionales Array. Das gesamte Projekt wird nach TDD entwickelt und bisher hatte ich mit der Klasse RawImage8Bpp KEINERLEI Probleme. Nun bei einem speziellen Test, bekomme ich sehr merkwürdige allokationen von Arrays (siehe Bild im Anhang).

Wenn ich ein byte[3,2,1] allokiere, bekomme ich als Resultat ein Array der Länge 3,2,1, ALLERDINGS befinden sich die Elemente der ersten Dimension in byte[255-257,x,y].
Wenn ich nun auf Data[0,x,y] zugreife knallt es, weil ja in 0 nichts drin steht sondern erst ab 255!

In dem Projekt wird sehr viel mit unsafe code gearbeitet, also könnte auch ein falscher Pointer das problem sein? Der code in dieser Methode (fixed & unsafe) diente nur zu Debug-Zwecken, normal ist die Methode safe und enthält nur die Allokation des Arrays.

Habt ihr soetwas schon mal gehabt?

Danke im voraus!

Gruß David

49.485 Beiträge seit 2005
vor 13 Jahren

Hallo DavidT,

mit new byte [Width, Height, 1] erzeugst du ein Array, bei dem die Indexierung für alle Dimensionen bei 0 beginnt. C# kann (im Gegensatz zur CLR) ohnehin nur mit Arrays umgehen, bei denen die Indexierung bei 0 beginnt.

Wo erfolgt dein Zugriff? In deinem Bild sehe ich nichts dergleichen.

herbivore

DavidT Themenstarter:in
998 Beiträge seit 2007
vor 13 Jahren

Noch als Anmerkung: Der Test knallt nur bei jedem 5. oder 6. durchlauf...

Hallo herbivore,

in der Zeile


fixed (byte* ptrSnapshot = Data)

erfolgt der Zugrif auf das erste Element (den Zeiger) und da knallt es... Wenn ich es per Indexer mache knallt es ebenfalls!

Das C# das normal macht, also das die Indexe bei 0 Anfangen ist mir beuwsst, aber hier ist es bei jedem 5. oder 6. durchlauf nicht so.

Gruß David

49.485 Beiträge seit 2005
vor 13 Jahren

Hallo DavidT,

in der Zuweisung wird noch nur die Adresse das Array zugewiesen. Ich sehe nicht, warum da ein Zugriff auf das erste Element erfolgen sollte. Wenn überhaupt geht es da um die Adresse des ersten Elements. Da das Ziel aber ein byte-Pointer ist, wüsste ich auch nicht, was das hinsichtlich der Offsets des Arrays überprüft werden sollte.

Warum der Debuger bei diesem Code in dieser Zeile was von 255..257 anzeigt, ist mir schleierhaft.

herbivore

DavidT Themenstarter:in
998 Beiträge seit 2007
vor 13 Jahren

Herbivore es knallt in der Zeile also greift er doch offensichtlich darauf zu oder? Die Exception die du im Bild siehst (IndexOutOfRange Exception) fliegt in der fixed zeile... Ein Pointer ist ein Zeiger auf das 0-te Element, das 0-te Element existiert aber nicht!

Er zeigt 255-257 an, weil das 0-te Element in array[255,x,y] ist, das 1-te in array[256,x,y] und das 3-te in [257,x,y] und genau da steigt mein Verständnis aus...

Gruß David

49.485 Beiträge seit 2005
vor 13 Jahren

Hallo DavidT,

wie gesagt, durch die Zeile new byte [Width, Height, 1] wird ein Array erzeugt, bei dem die Indexierung für alle Dimensionen bei 0 beginnt.

Erstelle man ein neues, kleines Testprogramm, dass aus nichts anderem besteht als dem new und der Zuweisung. Tritt der Fehler da auch auf? Wenn nicht ist vermutlich dein Projekt, dein VS oder der Debugger aus dem Tritt gekommen.

herbivore

DavidT Themenstarter:in
998 Beiträge seit 2007
vor 13 Jahren

Natürlich passiert es da nicht.

Der Fehler passiert auf 2 unabhängigen Entwicklermaschinen!

Gruß David

DavidT Themenstarter:in
998 Beiträge seit 2007
vor 13 Jahren

Hallo,

nach 9h suche haben wir den Fehler gefunden, für die suche es traten*FatalExecutionException *IndexOutOfRangeException *ApplicationException

Exceptions auf und zusätzlich wurden neue Arrays in der oben angesprochenen Weise allokiert.

Das problem lag in einer ganz anderen Methode, die zusätzlich mit der oben beschriebenen in einer Schleife aufgerufen wurde. Darin wurde mit einem Zeiger von einer StartAdresse bis zu einer EndAdresse neue Daten geschrieben. Die Berechnung der Endadresse war falsch und so hat er munter in die Daten geschrieben und scheinbar willkürlich dieses Problem verursacht.

Gruß David