Access Violation ( kann nicht herausfinden an welcher stelle

[jmd anders]

Hallo zusammen, ich hab ein programm geschrieben in dem nach einiger Zeit(mal dauerts länger >4h eine Access Violation auftritt, wenn ich dann auf break klicke, kriege ich nur das cpu fenster mit assembler anweisungen, ich kann dann noch zum delphi code switchen, da bleibt er aber mit dem roten balken an unterschiedlichen stellen stehen(also mal an dieser stelle, mal an einer anderen).
auf dem aufruf stack liegt dann als letzte anweisung sysallocem oder realloc mem.

es scheint, als scheine der fehler schneller zu kommen, wenn die systemauslastung größer ist, aber das ist nur eine waage vermutung.

daher würde ich gerne mal wissen, was eine access violation im eigentlich ist und wo sie am häufigsten vorkommt.

und wie kann ich vielleicht was anfangen, was in dem cpu fenster steht, oder wie kann ich an die stelle kommen an der in meinem code was falsch ist.

[3_of_8]

Eine AccessViolation ist eine Zugriffsverletzung, passiert dann, wenn du auf nicht zugewiesenen Speicher/nicht erzeugte Klassen zugreifen willst.

Eine AV ist der böseste Fehler, den es überhaupt gibt.

Das CPU-Fenster bringt dabei in 99% der Fälle gar nix, am besten du versuchst eher, den Fehler mit Breakpoints einzugrenzen.

[Bernhard Geyer]

Compiliere auch mal mit Debug-DCU's. Evtl bekommst Du dann Code zu Gesicht.

[Sunlight7]

Zitat von jmd anders:

... wenn ich dann auf break klicke.

Hast Du die Option "Bei Exceptions Anhalten" aktiviert (Kann in Deiner Delphi etwas anders heissen)?

Zitat von 3_of_8:

Eine AV ist der böseste Fehler, den es überhaupt gibt.

Hmm, ich find' ne GP Fault viel böser

[oki]

Hi,

suchebesonders an den Stellen wo du mit eigenen Zeigern (Pointer) arbeitest. Oft werden aus C-dll's Strukturen als Zeiger übergeben oder müssen an diese übergeben werden. Ich hatte auch schon mal so blöde Fehler. Da hat eine Dll einen Zeiger auf eine Struktur erwartet und ich hatte den Record nicht richtig definiert.

Gruß Oki

[jmd anders]

mit den debug dcus, bleibt der debugger an der stelle in getmem.inc stehen:
{Unlock the block type}
mov TSmallBlockType[ebx].BlockTypeLocked, al

[3_of_8]

Zitat von Sunlight7:

Hmm, ich find' ne GP Fault viel böser

Damit meinte ich Debuggbarkeit in Relation zur Häufigkeit.