Delphi-PRAXiS
Seite 2 von 5     12 34     Letzte »    

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Object-Pascal / Delphi-Language (https://www.delphipraxis.net/32-object-pascal-delphi-language/)
-   -   Absturz der Anwendung nach beenden eines Threads (https://www.delphipraxis.net/180808-absturz-der-anwendung-nach-beenden-eines-threads.html)

Captnemo 19. Jun 2014 14:26

AW: Absturz der Anwendung nach beenden eines Threads
 
Zitat:

Zitat von mjustin (Beitrag 1262884)
Zitat:

Zitat von Captnemo (Beitrag 1262868)
Wenn ich aber das Formular nicht anklicke, dann läuft das Programm weiter, erzeugt auch neue Thread, und verbindet sich auch per TCP mit dem Server. Das kann ich x-mal machen, solange ich nicht das Formular der Mainform anklicke.

Woher könnte sowas kommen?

Aus welcher Library stammt TWSocket, ICS? Von ICS wird ein Fensterhandle benutzt. Eventuell besteht hier ein Zusammenhang?
Zur Verwendung von TWSocket in Hintergrundthreads, die Property 'Multithreaded' und Hinweis auf ein Multihtreaded-Beispiel könnte das hier weiterhelfen:

How can I push a TWSocket's OnDataAvailable() event to a background thread in my Delphi 6 application?

Ja, ist von ICS. Das mit Multithreaded hatte ich schon gefunden und verwende das auch. Das war auch mein erste Gedanke, da ich da eine Zusammenhang vermutete.
Grundsätzlich gehe ich aber mal davon aus, dass eher ich einen Fehler mache als Francois Piette :)

mjustin 19. Jun 2014 14:32

AW: Absturz der Anwendung nach beenden eines Threads
 
Läßt sich das Problem anhand eines minimalen Beispielprojekts reproduzieren (das man dann hier posten könnte)?

madExcept würde ich bei Abstürzen auch als allererstes benutzen um den Callstack zu erhalten. (es ist fast schon ein must-have Werkzeug).

Captnemo 19. Jun 2014 15:34

AW: Absturz der Anwendung nach beenden eines Threads
 
Also ich habe mir jetzt im Thread im OnTerminate per PostMessage eine Message an den Hauptthread schicken lassen.

Dann rufe ich folgende Procedure auf

Delphi-Quellcode:
  Writelog('Message TCPComThreadEnded empfangen');
  for I := ComThreadList.Count-1 downto 0 do
  begin
    if TTCPThread(ComThreadList[i]).Finished then
    begin
      Writelog('FreeAnNil TCPComThread');
      TTCPThread(ComThreadList[i]).Free;
      Writelog('Thread aus TObjectList entfernen');
      ComThreadList.Delete(i); //<- Hier tritt eine Exception auf, dass das Object nicht mehr da ist.
    end;
  end;
Erzeugen tu ich es so:
Delphi-Quellcode:
  TCPThread:=TTCPThread.Create(False, '192.168.177.71', localport, ip, port, self.Handle);
  ComThreadList.Add(TCPThread);
Muß ich es auf der ComThreadList nicht mehr löschen?

Wenn ich bei ComThreadList.Delete(i) eine Haltepunkt setze, und alle im Einzelschritt durchgehe, dann lande ich in der Unit "System.Classes" in der Funktion "TThread.destroy".
Das kommt aber wahrscheinlich durch den Aufruf von .Free (2 Zeilen drüber).

Und ich lande hier:
Delphi-Quellcode:
destructor TThread.Destroy;
begin
  if (FThreadID <> 0) and not FFinished and not FExternalThread then
  begin
    Terminate;
    if FCreateSuspended or FSuspended then
      Resume;
    WaitFor;
  end;
  RemoveQueuedEvents(Self);
{$IF Defined(MSWINDOWS)}
  if (FHandle <> 0) and not FExternalThread then CloseHandle(FHandle);          //<- Hier habe ich eine Exception:
       // Im Project WSPRG.exe ist eine Exception der Klasse $C00000005 mit der
       // Meldung 'Zugriffsverletzung bei 0x00000000: Lesen von Adresse 0x00000000' aufgetreten


{$ELSEIF Defined(POSIX)}
  // This final check is to ensure that even if the thread was never waited on
  // its resources will be freed.
  if (FThreadID <> 0) and not FExternalThread then pthread_detach(pthread_t(FThreadID));
{$IF Defined(MACOS)}
  pthread_mutex_destroy(FCreateSuspendedMutex);
{$ELSEIF Defined(LINUX)}
  sem_destroy(FCreateSuspendedSem);
{$ENDIF LINUX}
{$ENDIF POSIX}
  inherited Destroy;
  FFatalException.Free;
end;

Uwe Raabe 19. Jun 2014 15:42

AW: Absturz der Anwendung nach beenden eines Threads
 
Zitat:

Zitat von Captnemo (Beitrag 1262890)
Wenn ich bei ComThreadList.Delete(i) eine Haltepunkt setze, und alle im Einzelschritt durchgehe, dann lande ich in der Unit "System.Classes" in der Funktion "TThread.destroy".
Das kommt aber wahrscheinlich durch den Aufruf von .Free (2 Zeilen drüber).

Das kommt eher daher, daß das Delete auch gleichzeitig die Instanz freigibt, die dann natürlich nicht mehr existiert. Lass doch mal das Free zwei Zeilen drüber weg.

Captnemo 19. Jun 2014 16:37

AW: Absturz der Anwendung nach beenden eines Threads
 
Okay, das funktioniert :-) Danke Uwe.

Allerdings besteht mein ursprüngliches Problem immer noch.
Jetzt habe ich mir mal das MADExcept heruntergeladen und auch in den madexcept Settings aktiviert. Meine Exe wird auch größer, und jetzt sollte doch eigentlich bei einer Exception ein Fenster mit Debuginfo's kommen. Allerdings bekomme ich nach wie vor entweder die Fehlermeldung von Windows, oder er geht ins Debugging der IDE. Muß man noch was anderes machen, damit madexcept die Exception abfängt?

himitsu 19. Jun 2014 16:39

AW: Absturz der Anwendung nach beenden eines Threads
 
Entweder du sagst der Objektliste die soll das löschen (OwnsObjects) und selber löschst du das nicht mehr,
wobei hier das Delete die TThread-Instance löscht.

Aber wenn du das unbedingt selber löschen willst, dann darf entwedet die Liste das nicht automatisch löschen (kein OwnsObjects)
oder du mußt den "ungültigen" Zeiger via TObjectList.Extract rausholen.

Captnemo 19. Jun 2014 16:44

AW: Absturz der Anwendung nach beenden eines Threads
 
Ich habe jetzt OwnObjects:=False und lösche das Object jetzt selber. Das Free hab ich rausgenommen und so funktioniert es jetzt auch.
Aber mein Ursprüngliches Problem ist noch da und das mit dem madexcept will auch nicht funktionieren (Wär ich heut bloß im Bett geblieben)

Uwe Raabe 19. Jun 2014 16:49

AW: Absturz der Anwendung nach beenden eines Threads
 
Zitat:

Zitat von Captnemo (Beitrag 1262901)
Jetzt habe ich mir mal das MADExcept heruntergeladen und auch in den madexcept Settings aktiviert. Meine Exe wird auch größer, und jetzt sollte doch eigentlich bei einer Exception ein Fenster mit Debuginfo's kommen. Allerdings bekomme ich nach wie vor entweder die Fehlermeldung von Windows, oder er geht ins Debugging der IDE. Muß man noch was anderes machen, damit madexcept die Exception abfängt?

Der IDE-Debugger hat Vorrang. Wenn du das Programm dann in der IDE weiterlaufen lässt, sollte madExcept zuschlagen. Oder einfach ohne Debugger starten.

Wenn Windows die Exception fängt, dann müsste man das mal genauer untersuchen, wo die Exception hochkommt. Hast du alle Checks (Range checking, Overflow checking) aktiviert?

Captnemo 19. Jun 2014 17:24

AW: Absturz der Anwendung nach beenden eines Threads
 
Liste der Anhänge anzeigen (Anzahl: 1)
Okay, das mit den madexcept läuft jetzt. Ich habe eine bugreport, aus dem ich selbst leider nicht so viel herauslesen kann. Ich häng den mal an Anhang dran, vielleicht kann jemand etwas daraus erkennen.

Wenn ich dann in der madException auf Continue Application klicke, läuft meine Anwendung scheinbar weiter, bis ich der Mainform mal wieder den Focux spendiere.

himitsu 19. Jun 2014 17:37

AW: Absturz der Anwendung nach beenden eines Threads
 
Zitat:

Zitat von Captnemo (Beitrag 1262904)
Ich habe jetzt OwnObjects:=False und lösche das Object jetzt selber. Das Free hab ich rausgenommen und so funktioniert es jetzt auch.
Aber mein Ursprüngliches Problem ist noch da und das mit dem madexcept will auch nicht funktionieren (Wär ich heut bloß im Bett geblieben)

Du hast jetzt das Free weggemacht und das OwnObjects auch und das FreeOnTerminate ist ebenfalls nicht aktiv?
Es gibt also nur noch das Delete in der Liste.

Nja, dann hast du den Thread-Zeiger nun aus der Liste, aber die Thread-Instanz gammelt als Speicherleck immernoch im Programm rum.
Einwas davon mußt du schon noch machen (nur Eines und nicht Mehreres).


Alle Zeitangaben in WEZ +1. Es ist jetzt 06:33 Uhr.
Seite 2 von 5     12 34     Letzte »    

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