Delphi 2009 - Programm hängt manchmal beim beenden

[bwolf]

Hi Leute,

ich habe das Problem das mein Programm nach dem Beenden manchmal (etwa jedes 2. Mal) hängen bleibt.
Es kommt dann die Fehlermeldung "Programm.exe reagiert nicht mehr".
Im Ereignisprotokoll von Delphi 2009 ist dann die letze Meldung: "Modul entladen: OLEPRO32.DLL"

Wenn ich das Programm direkt ausführe und es beende hat das bisher immer problemlos geklappt.
Hat jemand einen Tip wie man das debuggen kann?
Danke euch!

[mkinzler]

Verwendest du OLE-Automatisierung von Officeprodukten o.ä.?

[bwolf]

Hi,
es wird eine Type Library verwendet um in einer anderen Anwendung eine Funktion aufzurufen.

[mkinzler]

Entlade diese mal manuell

[s.h.a.r.k]

Gibt es eine Liste von DLLs, die ich manuel entladen muss?! Denn ich habe den "Fehler" (oder wie auch immer man das nennen mag) auch an ein paar Stellen. Die einzigen DLLs mit "OLE" im Namen, die beim Ausführen des problematischen Codes geladen werden, aber laut IDE nicht entladen werden, sind bei mir OLEDB32.dll und MSJETOLEDB40.dll. Daneben gibt es aber auch noch weitere 40-50 Stück.

Was mache ich: ich erzeuge beim OnClick auf einen Button einen neuen TOpenDialog und führe diesen aus. Wählt der Benutzer einen Dateinamen (es handelt sich hierbei um eine Access-Datenbank-Datei) aus, so wird dieser in ein Edit geschrieben. Beim OnChange werden die Tabellen aus der DB geladen und die Verbindung (TADOConnection) wieder abgebaut.

[bwolf]

Also ich habe es mit manuellen entladen probiert, allerdings ohne Erfolg.

Allerdings scheint das Problem auch wo anders zu liegen...
Und zwar wird er bei mir anscheinend durch folgendes Verursacht:

Ich habe ein TClientDataSet, das ich im onShow der Form öffne.
Wenn dieses TClientDataSet NICHT geöffnet wird, habe ich beim beenden der Applikation auch das Problem nicht.
Wenn ich das TClientDataSet zur Laufzeit öffne und das Programm beende, ist der Hänger wieder da. Auch ein .close und .free auf das TClientDataSet behebt das Problem nicht. Sehr seltsam :|


@ s.h.a.r.k:
hast du zufällig auch ein TClientDataSet im einsatz?

[s.h.a.r.k]

Ich habe nur folgende Klassen im Einsatz: TADOConnection, TADOCommand, TADODataSet. Über diese stelle ich eine Verbindung zu einer dBase und einer Access-Datenbank her.

// edit

TClientDataSet und TADODataSet sind aber beide von der Basisklasse TDataSet abgeleitet.

[bwolf]

Hast du mal getestet ob der Fehler auch kommt wenn das Dataset nicht geöffnet wird?

[s.h.a.r.k]

TADOConnection bietet mit die Methode GetTableNames() an, die intern automatisch ein TADODataSet öffnet und die Tabellennamen aus der DB ausliest. Diese werden dann in eine TWideStringList geschrieben. Wenn ich diesen Aufruf einmal mache, dann klappt das wunderbar, aber kein zweites mal.

Greifst du evtl. über ODBC auf eine Datenbank zu?! Weil ich kurz davor bin, zu glauben, dass es daran liegt.

// edit

Habe mir nur ein Testprojekt geschrieben, welches eine Connection zu einer Access-DB öffnet, ebenso zu einer DBase-DB. Beides läuft über AnyDAC 2.0.17 und ich komme zum gleichen Resultat, wie über die ADO-Komponenten, ergo muss es irgendwie an den Basisklassen liegen. Mal schauen, was sich da noch so zeigen wird...

[s.h.a.r.k]

Hier nochmal eine Aktualisierung des Problems auf einen sehr minimalen Quellcode. Ich habe eine Form und ein Memo darauf, samt einem Button zum Anstoßen dieses Codes. Was machst das Ding? Es stellt eine Verbindung zu einer dBase-Datenbank her, welche ja nur über den Pfadnamen angegeben ist, liest die verfügbaren Tabellen aus und gibts diese aus. Danach wird die Verbindung wieder abgebaut und gut is.

Delphi-Quellcode:

var
  conn : TADOConnection;
  list : TStringList;
begin
  conn := TADOConnection.Create(nil);
  list := TStringList.Create();
  try
    conn.ConnectionString := 'Provider=MSDASQL.1;Persist Security Info=False;Data Source=dBASE Files;Mode=Read';
    conn.DefaultDatabase := DBASE_DIRECTORY; // this constant represents a path on the hdd
    conn.Connected := True;
    conn.GetTableNames(list);
    Memo1.Text := list.Text;
  finally
    conn.Connected := False;
    FreeAndNil(conn);
    FreeAndNil(list);
  end;
end;

Die Anwendung hängt sich bei mir nur dann auf, wenn die Delphi IDE diese im Debug-Mode ausgeführt hat. Starte ich diese ganz normal über den Explorer funktioniert alles wunderbar. Die Zeile

Delphi-Quellcode:

conn.Connected := True;

macht das Problem, nur was genau kann ich leider nicht sagen.
Ich sollte auch noch dazu sagen, dass innerhalb der

Delphi-Quellcode:

GetTableNames()

-Methode ein TADODataSet erzeugt, damit gearbeitet und freigegeben wird.

[Codewalker]

Ich habe ein ähnliches Problem, aber ohne Verwendung von Datenbankkomponenten. Es sind zwar eine Reihe von Komponenten mit dabei (JVCL, Andorra2D, etc.) - aber der Fehler ist auch nicht wirklich reproduzierbar. Manchmal beende ich das Programm und dann hängt Delphi und es dauert teilweise 20 Sekunden, bis der Debugger den Prozess wirklich schließt und Delphi wieder reagiert. Starte ich das Programm danach erneut und mache genau das gleiche kann es sein, dass es zu keinem Hänger kommt.
Wie würdet ihr so einen Fehler finden? Es bremst einen wirklich übelst beim Programmieren...

Edit: Habe auch mal alle .dcu-Dateien etc. gelöscht -> kein Effekt

[Codewalker]

*Push*
Bin bisher nicht weitergekommen - hat keiner eine Idee?

[Schorschi5566]

Hallo Codewalker,

auch wenn der Fehler nicht zu reproduzieren ist, musst Du ihn irgendwie eingrenzen.

Oder hängt Dein Programm auch, wenn Du gar nichts tust?

Unter welchen Umständen tritt das Problem auf? Tritt es auch ohne Delphi auf?

Wenn Du einen bestimmten Codeblock im Verdacht hast, versuche ihn mal wegzulassen oder mit anderem Code zu ersetzen oder natürlich zu debuggen.

Dann wirst Du dem Problem schon auf die Spur kommen. :)

Benutzt Du eigene Pointer? Wenn Delphi solche "Kunstpausen" macht, war es bei mir schon häufig so, dass ich irgendwo ganz übel im Speicher rumgemalt hatte. 8-)


Grüße,
Uwe

[Codewalker]

Zitat:

Zitat von Schorschi5566 (Beitrag 1040319)

Oder hängt Dein Programm auch, wenn Du gar nichts tust?

Nein, es geht ja darum, dass - wenn ich mein Programm beende - der Prozess nicht geschlossen wird. Und solange der Prozess läuft, kehrt der Debugger nicht zurück. Deswegen habe ich auch keinen Codeteil im Verdacht, weil das Debuggen da eigentlich schon vorbei ist. Ist habe in der Zwischenzeit mal AQTime benutzt und wollte herausfinden, wo er so lange verweilt, aber auch AQTime beendet die Zeitmessung vorher.

Zitat:

Zitat von Schorschi5566 (Beitrag 1040319)

Unter welchen Umständen tritt das Problem auf?

Keine Ahnung, passiert wahllos in ca. 40% der Fälle.

Zitat:

Zitat von Schorschi5566 (Beitrag 1040319)

Tritt es auch ohne Delphi auf?

Ja, aber dann fällt es nicht auf, weil es kein Fenster oder ähnliches gibt, sondern der Prozess nur noch für einige Sekunden im TaskManager zu sehen ist. Aber beim Debuggen ist das halt viel nerviger.

Zitat:

Zitat von Schorschi5566 (Beitrag 1040319)

Benutzt Du eigene Pointer? Wenn Delphi solche "Kunstpausen" macht, war es bei mir schon häufig so, dass ich irgendwo ganz übel im Speicher rumgemalt hatte. 8-)

Ich nicht, aber Andorra nutzt einige Konstrukte, um dynamisch mit Plugins arbeiten zu können. Das war aber bisher nie ein Problem.

Ich werde einfach mal in alle Units im finalization-Abschnitt ein OutputDebugString einbauen und dann mal sehen, wo ich überall ankomme. Evtl. hilft das weiter. :glaskugel:

[blackfin]

Das Problem habe ich auch manchmal...eine definierte Lösung habe ich dafür auch noch nicht gefunden.
Ich weiss nur, woran es ungefähr liegt, falls es bei dir auch um eine 3D-Applikation geht: Manchmal braucht der Treiber der Grafikkarte irgendwie unverschämt lange, um den Rendering Context zu deaktivieren. Manchmal ja, manchmal nein.
Ich habe bei mir das ganze schonmal runtergetrackt und gesehen, dass da anscheinend noch der Graka-Treiber Aufräumarbeiten tätigt, und das bei mir teilweise bis zu einer Minute!!!
Ich würde das auch gerne loswerden, da es wirklich nervt! Allerdings habe ich festgestellt, dass das teilweise auch bei kommerziellen Spielen auftritt, dass es ewig dauert, bis das Spiel endlich beendet wird.

[Codewalker]

:thumb: Das klingt treffend. Ich habe das in zwei Projekte, eines mit Andorra (definitiv mit 3D-Beschleunigung) und in einer Filmverwaltung mit CoverFlow (von TMsSoftware), dass auch eine DirectX-Surface nutzt. Von daher könnte genau dass bei mir auch die Ursache sein.
Einerseits beruhigt es mich ja, dass ich keinen Blödsinn programmiert habe, aber andererseits kann man dagegen auch nichts tun.
Vielen Dank für den Hinweis

[p80286]

Zitat:

Zitat von Codewalker (Beitrag 1040397)

Einerseits beruhigt es mich ja, dass ich keinen Blödsinn programmiert habe,..

Schau mal nach ob Du Dich nicht "verzeigert" hast. Das hatte bei mir mal solche Auswirkungen. (Früher oder später knallt's dann aber doch)

Und die Speicherfreigabe am Programmende kann manchmal arg lange dauern

Gruß
K-H

[Schorschi5566]

Halle Codewalker,

na ja, wenn es tatsächlich mit den Treibern der Grafikkarte zusammenhängt, könnte man ja mal verschiedene Treiber durchtesten und schauen ob sich das Verhalten ändert. :)

Ich habe mal 'nen Sudoku-Pseudo-Solver gebaut, der bei manchen Lösungsansätzen auch noch ewig nach der Lösung "rumgemacht" hat. Mehr als 10 Sekunden waren das aber nie und das waren offenbar nur Aufräumarbeiten, die Delphi durchgeführt hat, wenn viele Objekte gelöscht werden.

Kann also auch ohne 3D-Kram passieren. ;)


Grüße,
Uwe

[zeras]

Ich habe auch öfters einmal, wenn ich den ganzen Tag programmieren und debugge, dass sich D2009 aufhängt. Dann kommt manchmal beim Speichern eine Meldung und danach geht gar nichts mehr. Dann heißt es nur noch Windows runterfahren und neu starten in der Hoffnung, dass vorher alles gesichert war. Letzten Sonntag war es wieder so weit. Wie gesagt, habe ich D2009 und TMS und nun ein wenig getestet mit Firebird und IB. Ich muss wahrscheinlich dann Mittags mal Runterfahren und neu starten. Dann hält es meistens bis zum Abend durch.