Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Object-Pascal / Delphi-Language (https://www.delphipraxis.net/32-object-pascal-delphi-language/)
-   -   Delphi Unit in Klasse übertragen -> Access Violation (https://www.delphipraxis.net/151919-unit-klasse-uebertragen-access-violation.html)

CorVu5 6. Jun 2010 22:04

Delphi-Version: 2005

Unit in Klasse übertragen -> Access Violation
 
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo Leute,
Ich stieß in einem russischen Forum auf eine Unit, die einen SOCKS5-Server erstellen soll.
Diese Unit funktioniert auch gut. (soweit ich das testen konnte)

Originalunit: http://nopaste.info/1b154eaa8c.html

Für meine Zwecke ist diese Methode aber eher ungeeignet, glücklicherweise fand ich auf der selben Seite eine Umarbeitung der Unit zur Klasse. (Siehe Anhang)


Unglücklicherweise schmeißt diese mir beim Aufruf von FOnClientConnected eine AV aus.
Kommentiere ich FOnClientConnected aus, kommt zwar keine AV und wird der Socket auch erstellt, die anderen Events werden jedoch nie aufgerufen und der Server reagiert nicht auf SOCKS-Anfragen.

Ich bin leider alles andere als ein Experte in OOP und würde hier nun gerne nachfragen, was mein Fehler sein könnte.
Mein Beispielcode sieht so aus:
Delphi-Quellcode:
type TProxyMethodDispatcher = class(TObject)
    public
      procedure ClientConnected(client:TSocket);
      procedure ClientDataAvailable(client:TSocket; data:pchar; len:integer);
      procedure ClientDisconnected();
end;

procedure TProxyMethodDispatcher.ClientConnected(client:TSocket);
begin
  MessageBoxA(0,pchar('PROXY Connected'),'ff',0);
end;
procedure TProxyMethodDispatcher.ClientDataAvailable(client:TSocket; data:pchar; len:integer);
begin
  MessageBoxA(0,pchar('PROXY ' + string(data)),'ff',0);
end;
procedure TProxyMethodDispatcher.ClientDisconnected();
begin
  MessageBoxA(0,pchar('PROXY DisConnected'),'ff',0);
end;
var
  vproxysock : TSocks5Proxy;
  vproxymethoddispatcher : TProxyMethodDispatcher;
begin

  vproxysock := TSocks5Proxy.Create(nil);
  vproxysock.OnClientConnected := vProxyMethodDispatcher.ClientConnected;
  vproxysock.OnClientDisConnected := vProxyMethodDispatcher.ClientDisConnected;
  vproxysock.OnClientDataAvailable := vProxyMethodDispatcher.ClientDataAvailable;
  //SOCKS5 SOCKET

  vproxysock.Port := 8080;
  vproxysock.UseAuth := False;
  vproxysock.ManualResponse := True;
  vproxysock.Open;
end;
Danke im Voraus

Zacherl 6. Jun 2010 22:13

AW: Unit in Klasse übertragen -> Access Violation
 
Im Dispatcher selbst kannst du nicht viel falsch machen. Hat du das Dispatcher Objekt denn überhaupt mit Create erzeugt? Manchmal sinds die einfachen Sachen, die man vergisst :D In der Unit selbst wird auch nichts großartig gemacht, was vor oder nach dem OnClientConnected Event eine AV auslösen könnte.

CorVu5 6. Jun 2010 22:46

AW: Unit in Klasse übertragen -> Access Violation
 
Du hast Recht, das Problem schein wo anders zu liegen.
Möglicherweise irgendeine Art von Threadproblem:
Beim Debuggen fiel mir folgendes auf:
Delphi-Quellcode:
CreateThread(nil, 0, @TSocks5Proxy.Socks5Server, Pointer(servsocket), 0, TId);
Dabei ist servsocket ein gültiger Pointer, bind und listen werden ordnungsgemäß ausgeführt.
In der procedure Socks5Server hat servsocket jedoch plötzlich einen ganz anderen Wert (immer irgendwas über 4000000), was dann natürlich kein gültiger Socket mehr ist und accept ohnehin fehlschlagen lässt.
Also liegt es am Threading?
Was muss ich spezielles beim Threading mit Objekten, bzw. deren Events und Methoden wissen?

Luckie 6. Jun 2010 22:53

AW: Unit in Klasse übertragen -> Access Violation
 
Benutze nicht die API-Funktion CreateThread direkt, sondern den Delphi Wrapper BeginThread, da BeginThread dafür sorgt, dass der Heap threadsafe ist.

CorVu5 6. Jun 2010 23:07

AW: Unit in Klasse übertragen -> Access Violation
 
Gesagt, getan.
Leider immer noch AV, nur dass jetzt die Exceptions offenbar greifen. :(
"Error 5: Zugriff verweigert"

//Edit: Die AV tritt jetzt schon vorher, bei "while FWorking do" auf, irgendwie scheinen die Eigenschaften des Objekts vom Thread aus nicht zugänglich zu sein? :-/

Luckie 7. Jun 2010 00:27

AW: Unit in Klasse übertragen -> Access Violation
 
Na bitte dann funktioniert doch alles. Jetzt musst du nur noch rausbekommen, warum dir die nötigen Rechte fehlen. Was passiert, wenn du das Programm als Administrator startest?

CorVu5 7. Jun 2010 13:11

AW: Unit in Klasse übertragen -> Access Violation
 
Ändert leider überhaupt nichts.
Ich bin wirklich ratlos, vor Allem, da ich mich wie gesagt mit OOP noch nicht besonders gut auskenne.

brechi 7. Jun 2010 18:46

AW: Unit in Klasse übertragen -> Access Violation
 
Also entweder du deklarierst die procedure Socket5Server als stdcall oder verwendest BeginThread anstatt CreateThread.
Außerdem geht ich mal davon aus, dass dies KEINE Methode einer Klasse ist sondern wie im NoPaste eine einfache Prozedure ist. Es darf keine Methode sein, weil bei einer Methode IMMER noch ein zusätzlicher Parameter verwendet wird (self).

CorVu5 11. Jun 2010 21:24

AW: Unit in Klasse übertragen -> Access Violation
 
Ich glaube, ich beginne zu verstehen.
Socks5Server ist wie im Snippet gezeigt eine Methode der Klasse.
Folglich kann CreateThread gar nicht funktionieren, weil ein Methodenzeiger etwas anderes ist als ein Funktionszeiger und immer noch ein weiterer Parameter übergeben wird.
Nun könnte ich natürlich Socks5Server als normale Prozedur deklarieren, das Problem dabei ist nur, dass ich dann selbstverständlich nicht mehr auf die Propertys der Klasse zugreifen kann ("Fworking" zum Beispiel). Nun könnte ich natürlich irgendwelche Wrapperfunktionen schreiben, aber das würde wohl kaum dem Gedanken der objektorientierten Programmierung entsprechen.
Gibt es keine einfache Möglichkeit, die Methode wie eine normale Funktion mit Beginthread zu starten?
Oder muss ich per Inline ASM den zusätzlichen Parameter pushen?


Alle Zeitangaben in WEZ +1. Es ist jetzt 08:31 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz