Seltsamer Fehler... mit "invalid memory access"

[Dostej]

Ich habe einen seltsamen Fehler, den ich überhaupt nicht verstehe.
Ich rufe eine Proc auf. Geht. beim Dritten aufruf kommt ein "invalid memory access" beim Befehl "Displaysprite3d()". Das Sprite exisitert (direkt vor Aufruf getestet).

Ich bin daher geneigt, den Fehler PB in die Schuhe zu schieben.
Oder hat jemand ne Lösung für das Problem?

(Ich verwende keine Threads)

[#NULL]

falls du eine variable benutzt: ist sie in der proc bekannt (global/parameter)?
teste gültigkeit des sprites doch mal direkt in der proc.

[Dostej]

@Null
Nein, ist ne Konstante, habe direkt vor dem Aufruf getestet, ob das Sprite3d exisitiert. Auch die Parameter sind feste NUmmern. Deshalb versteh ich den Fehler ja nicht...

[NicTheQuick]

Erstellst du zwischenzeitlich vielleicht ein Sprite mit der selben Nummer, das
du dann löschst?

Ansonsten: Quellcode her!

[HeX0R]

Invalid Memory Access-Errors bleiben in den seltensten Fällen in der richtigen Zeile hängen.
Du solltest dir mal den Weg zu diesem Befehl genauer anschauen.

Richtig irre wird es, wenn du so nen Fehler bekommst und Threads UND Dlls verwendest... dann Prost Mahlzeit

[Hellhound66]

Mögliche Gründe:

-Defekte DLL
-DLL-Prozedure mit der falschen Anzahl an Parametern aufgerufen.
-Prototype falsch deklariert oder definiert.
-CallFunctionFast mit den falschen Parametern aufgerufen.
-Assemblerroutinen, die unsauber arbeiten und ein PUSH oder POP zuviel haben.

Eigentlich treten IMA nur dann auf:
- Ein Fehler auf dem Stack entstand dadurch, dass falsche (Anzahl an) Parameter oder ähnliches benutzt wurden. Dann bleibt das Programm entweder an einem Funktionsaufruf hängen, oder aber (sehr charakteristisch) an einem ProcedureReturn/EndProcedure.
- Durch den Fehler auf dem Stack, wurden lokale Variablen ungültig oder verschoben. Wenn sich jetzt ein Handle oder ein Pointer auf dem Stack befandt ist dieser auf ungültig oder schlicht falsch geworden. Ein Zugriff darauf oder ein Funktionsaufruf, der diesen Handle benötigte wird höchstwahrscheinlich abstürzen.
- Du arbeitest schlichtweg mit falschen Pointern oder Handles aufgrund eines eigenen Fehlers.
- Eine DLL / LIB hat Schei$e gebaut.
- Du nutzt mehrere Threads, die sich beissen.

[Dostej]

Hm, erst mal Danke...

Also einiges kann ich mal ausschliessen...
Ich verwende keine Prototypen, rufe eine DLL-proc auf, kein CallFunctionFast, AFAIK auch keine Assemblerroutinen, keine Threads.

Ich verwende eine eigene Lib. Evtl. das da ein Fehler drin ist.

@NTQ

Erstellst du zwischenzeitlich vielleicht ein Sprite mit der selben Nummer, das
du dann löschst?

Das könnte es evtl. noch sein. Werds mal heute abend testen.
Wenn ich den Fehler nicht finde, kann ich Dir gerne den Code überlassen (sind mittlerweile ca. 700 k)

//EDIT
Konnte es nicht lassen, doch schnell noch was ausprobieren...
Habe den Displayspritebefehl ausgremmt, dann läuft es problemlos.
Habe auch direkt davor mit "savesprite" das Sprite für das 3d-sprite gespeichert. Es ist immer das gleiche. Auch ISsprite udn isSprite3D zeigen je die gleiche Nummer an. Ich verstehs nicht...

[THEEX]

Wenn ich einen Fehler nicht finde und vermute, daß es an PureBasic liegt, versuche ich diesen mit einem kleinen einfachen Programm zu reproduzieren. Oft erkennt man erst da den eigenen Fehler, bzw kann man da mit großer Wahrscheinlichkeit ausschliessen, daß es an an einem selbst hängt. Also ich würde erst mal das versuchen, bevor ich ohne jeglich erklärbaren Grund einen PureBasic-Bug melde.

[Hellhound66]

3DSprites unterliegen strengen Konventionen unter PB. Das ist Manipulation immer schwierig. Die kleinste Unachtsamkeit und es gibt einen Fehler. Normalerweise aber keinen IMA.

[Dostej]

@CSprengel: Ups, ich wollte keinen Bug melden. Ich habe nur vermutet, es könnte einer sein.
Ich wüsste ja nicht, was ich genau melden sollte.

@Hellhound

3DSprites unterliegen strengen Konventionen unter PB.

Was sind das für Konventionen?
Ich sehe iM nur das mit den Basissprite. Was übersehe ich?