Fehler "access violation" - keine Ahnung, warum...

[DeddyH]

Kannst Du mir Deinen Gedankengang hier einmal erklären?

Zitat:

Delphi-Quellcode:

new(zeiger);
zeiger := NIL;

Und wird der übergebene Zeiger von der Funktion COM_TcpOpen tatsächlich verändert, oder werden nur die dahinterstehenden Daten befüllt?

[himitsu]

Geh mal in die Projektoptionen und aktiviere dort die Bereichsprüfung und eventuell noch die Debug-DCUs.

[Pow3rus3r]

Zitat von DeddyH:

Kannst Du mir Deinen Gedankengang hier einmal erklären?

Zitat:

Delphi-Quellcode:

new(zeiger);
zeiger := NIL;

Und wird der übergebene Zeiger von der Funktion COM_TcpOpen tatsächlich verändert, oder werden nur die dahinterstehenden Daten befüllt?

Der Zeiger wird eigentlich nur auf NIL gesetzt, damit ich sehen kann, ob er initialisiert wurde (von der Hardware) oder nicht. Sonst hätte der neue Zeiger schon von beginn an irgendeinen Wert und es wäre nicht ersichtlich, ob der wert von der Hardware zugewiesen wurde oder ob er einfach nur ein Zufallswert ist, der bei der zeigererzeugung zugewiesen wurde.

Die Funktion COM_TCpOpen weist dem Zeiger einen Wert zu (vorher NIL, nachher ein hardwarespezifischer Wert).

[Pow3rus3r]

Zitat von himitsu:

Geh mal in die Projektoptionen und aktiviere dort die Bereichsprüfung und eventuell noch die Debug-DCUs.

Das bringt mir dann folgende Meldung im Debugger:

Code:

   LOCK DEC     [EDX-skew].StrRec.refCnt        { threadsafe dec refCount       }

Und diese Meldung befindet sich in dieser Prozedur:

Code:

procedure _UStrArrayClr(var StrArray; Count: Integer);
{$IF not defined(CPU386)}
var
  P: Pointer;
begin
  P := @StrArray;
  while Count > 0 do
  begin
    _UStrClr(P^);
    Dec(Count);
    Inc(NativeInt(P), SizeOf(Pointer));
  end;
end;
{$ELSE}
asm
        { ->    EAX pointer to str      }
        {       EDX cnt                 }

        {$IFDEF ALIGN_STACK}
        SUB     ESP,4
        {$ENDIF ALIGN_STACK}
        PUSH    EBX
        PUSH    ESI
        MOV     EBX,EAX
        MOV     ESI,EDX

@@loop:
        MOV     EDX,[EBX]                       { fetch str                     }
        TEST    EDX,EDX                         { if nil, nothing to do         }
        JE      @@doneEntry
        MOV     dword ptr [EBX],0               { clear str                     }
        MOV     ECX,[EDX-skew].StrRec.refCnt    { fetch refCnt                  }
        DEC     ECX                             { if < 0: literal str           }
        JL      @@doneEntry
   LOCK DEC     [EDX-skew].StrRec.refCnt        { threadsafe dec refCount       }
        JNE     @@doneEntry
        LEA     EAX,[EDX-skew]                  { if refCnt now zero, deallocate}
        CALL    _FreeMem
@@doneEntry:
        ADD     EBX,4
        DEC     ESI
        JNE     @@loop

        POP     ESI
        POP     EBX
        {$IFDEF ALIGN_STACK}
        ADD     ESP,4
        {$ENDIF ALIGN_STACK}
end;
{$IFEND}

Das sind für mich allerdings alle böhmische Dörfer

[EWeiss]

Bist sicher das der Zeiger identisch ist mit dem der als rückgabe bei open erzeut wird?
Hatte auch mal ein probleme das ein zeiger aus unerklärlichen gründen gelöscht bzw.. nicht gleich war.

gruss

[DeddyH]

Wie sieht denn das Headerfile zu der DLL aus? Eigentlich gibt es ja nur 2 Möglichkeiten:
- die DLL fordert den Speicher an, befüllt ihn und gibt den Zeiger zurück
- die DLL erwartet einen Zeiger auf selbst angeforderten Speicher und befüllt diesen

Auf jeden Fall vermute ich, dass das ein Zeiger auf den Record sein soll und kein untypisierter. Die Kombination von New() und anschließendem NULLen macht zumindest keinen Sinn.

[Pow3rus3r]

Zitat von DeddyH:

Wie sieht denn das Headerfile zu der DLL aus? Eigentlich gibt es ja nur 2 Möglichkeiten:
- die DLL fordert den Speicher an, befüllt ihn und gibt den Zeiger zurück
- die DLL erwartet einen Zeiger auf selbst angeforderten Speicher und befüllt diesen

Auf jeden Fall vermute ich, dass das ein Zeiger auf den Record sein soll und kein untypisierter. Die Kombination von New() und anschließendem NULLen macht zumindest keinen Sinn.

Der Zeiger müsste eigentlich stimmen, denn mit falschem Zeiger macht die hardware garnichts bei Aufruf der entsprechenden Funktionen. Aber nach Aufruf der Funktionen startet die hardware wie gewünscht eine Signalmanipulation. Auch dürfte die Funktion sonst keine 0 als Rückgabewert (Ausführung ok) liefern.

[sx2008]

Ich würde empfehlen erst mal richtig aufzuräumen.
Dazu gehört dass das Record TManipulationtag sowie die Deklarationen für function COM_TcpOpen usw. in eine eigene Unit verschoben werden.

Alles was zur Ansteuerung der DLL benötigt wird muss in eine eigene Unit gepackt werden.
Alles andere wäre unprofessionell.

Delphi-Quellcode:

unit HwCom;
{
Hier Doku über die DLL (Hersteller, Zweck, Webseite,...) rein

}


interface

uses
  Windows;

 type
  TManipulationtag = record
    TriggerType: byte; ///< Trigger 1: Identify whether the TriggerValue is an address or a value (0: trigger not active; 1:   
  // ...
  end;

function COM_TcpOpen(var zeiger:Pointer; ipAddress:AnsiString; port:smallint): NativeUInt; stdcall;
...

implementation

const HWCOM_DLL = 'HwCom.dll';

function COM_TcpOpen(var zeiger:Pointer; ipAddress:AnsiString; port:smallint): NativeUInt; stdcall; external HWCOM_DLL;
...

end;

Die Unit HwCom wird dann per Uses in deiner Formularunit eingebunden.
Und dabei fällt mir sogleich ein Problem auf:
Du übergibst den Parameter ipAddress als AnsiString . Dieser Datentyp ist aber unter C/C++ unbekannt und dürfte wohl eher ein PAnsiChar sein.

[Pow3rus3r]

Zitat von EWeiss:

Bist sicher das der Zeiger identisch ist mit dem der als rückgabe bei open erzeut wird?
Hatte auch mal ein probleme das ein zeiger aus unerklärlichen gründen gelöscht bzw.. nicht gleich war.

gruss

Ja, der Zeigerinhalt ist gleich dem Rückgabewert der TcpOpen Funktion.

[himitsu]

Zitat von Pow3rus3r:

Das sind für mich allerdings alle böhmische Dörfer

Wichtiger wäre an der Stelle, der Stacktrace.
Du weißt jetzt wo es knallt, also beim Freigeben eines String-Arrays, bzw. mehrerer Strings,
aber irgendwer hat ja diese Prozedur aufgerufen und bei dem könnte man nachsehn, was er "genau" freigeben will, also welche Strings/Stringvariablen das sind
und dann hat man einen Anhaltspunkt, wo man eventuell nach der Ursache suchen könnte.

Aber eventuell hast du ja irgendwo Bufferoverrun, welcher zufällig diese Stringvariablen überschreibt.