BDE hängt!

[smaug]

Hallo,

ich verwende 3 Programme, die über BDE auf Datenbanken zugreifen.
Ein Server, der als Dienst läuft, eine Client-Oberfläche und ein C-Programm mit einer in Delphi geschriebenen DLL.
Das C-Programm wird vom Server mit CreateProcess gestartet.

Wenn alle drei zusammen laufen, hängt die BDE.
Die DLL kommt dabei als letztes, öffnet eine Tabelle, schreibt einige Sätze und schließt sie wieder. Alles ohne Fehler.
Das seltsame ist, dass das C-Programm bis zum Ende durchläuft, GetExitCodeProcess mir aber 128 zurückliefert. Beim nächsten Zugriff auf Tabellen frieren sowohl Server als auch Client ein. Genauer gesagt: TTable.open auf dem Server kehrt nicht zurück; das mit einer TQuery verbundene DBGrid wird nicht mehr gezeichnet.

In allen drei Programmen verwende ich dasselbe NetDir und jeweils ein eigenes PrivateDir. Der Client erzeugt allerdings auch LCK-Dateien im DB-Verzeichnis!?
Das ganze läuft auf Win200 Workstation. BDE Version 5.11. Der Benutzer hat Amdinrechte, der Dienst läuft unter System.

LOCAL SHARE steht auf true, damit ich die LCK-Dateien besser verfolgen kann. Das macht aber keinen Unterschied.

Ich hab' keine Ahnung mehr wo ich den Fehler noch suchen soll.

[mkinzler]

Was<macht ie Dll genau? Vielleicht erzeugt diese Locs die nicht mehr entfernt werden?

[Bernhard Geyer]

1, Um zu checken ob du nicht einfach Speicherlücken im Bereich DB-Komponenten hast häng mal FastMM4 rein

2, Von deinem geschilderten System von einem Client und Server zu reden ist etwas zu viel des guten. Wenn es wirklich Client/Server wäre, hättest Du den DB-Zugriff und die Kompos eh nur auf dem Server und eine passende Schnittstelle wie die anderen Komponenten mit dem Server kommunizieren.

3, Nur der obligatorische Satz: Schmeiß die BDE weg. Wie du merkst bekommt man (trotz der Betrachtung aller möglichen bekannten) Fehlerquellen immer wieder Probleme. Aber ich will nicht weiter ausholen. Probier erstmal Punkt 1 um zu sehen obs evtl. nur "triviale" Speicherlücken sind.

[smaug]

Die DLL wird mehrfach aufgerufen.
Beim ersten Mal wird PrivateDir und NetDir von Session gesetzt und eine Tabelle geöffnet, die von den anderen beiden Programmen nicht verwendet wird, aber im gleichen Verzeichnis liegt.
Bei jedem Aufruf wird ein Datensatz hinzugefügt oder geändert, die Tabelle bleibt dabei offen.
Beim letzten Aufruf wird die Tabelle geschlossen und freigegebn.
Ausser schreiben in eine Logdatei, die auch sauber geschlossen wird, macht die DLL nichts.

Ich werde die Programm von nun an Dienst und Oberfläche nennen, ok? Eine Schnittstelle für schreibenden Zugriff auf die Datenbanken ist übrigens vorhanden. Die Oberfläche öffnet nur TQuerys und TTable im Browse-Modus.

FastMM hab ich in uses eingebunden. Im C-Programm allerdings nicht, das ist nicht mit Borland kompiliert. Und nu?

[smaug]

Wenn die Oberfläche zu ist und die DLL somit sauber durchläuft, bleiben auch kein LCK-Dateien liegen.

[Bernhard Geyer]

Zitat:

Zitat von smaug

FastMM hab ich in uses eingebunden. Im C-Programm allerdings nicht, das ist nicht mit Borland kompiliert. Und nu?

Muss noch mit Debug-Infos im FullDebugMode arbeiten damit auch FastMM meckert.

[smaug]

Das ist interessant, mit FastMM bleibt jetzt schon das C-Programm hängen, die BDE bleibt aber verschont, sofern die Oberfläche keine Query offen hat.
Hat die Oberfläche eine Query offen, kommt das C-Programm weiterhin mit 128 zurück und es wird keine Logdatei erstellt.

Im MemoryManager_Event.log findet sich

Zitat:

5 - 12 bytes: TIniFile x 1
13 - 20 bytes: TObjectList x 3, Unknown x 3
21 - 28 bytes: TCriticalSection x 1
29 - 36 bytes: TWinHelpViewer x 1
37 - 44 bytes: String x 1
45 - 60 bytes: THelpManager x 1

Das IniFile habe ich definitiv freigegeben, der Rest ist mir vollkommen unbekannt ...?

[Bernhard Geyer]

Hast Du TWinHelpViewer und THelpManager kannst Du vergessen. Evtl. auch noch die Units von Helpware im Einsatz. Fehler ist dort zu suchen bzw. in WinHelpViewer.pas und HelpIntfs.pas

Pack noch Debug-DCU's dazu und schau dir mal die Log-Dateien an. Dort ist der Aufrufstack für deine Speicherlücken drin.

[smaug]

Mit den Helpdingern hab ich nix zu schaffen:

Zitat:

[HelpIntfs.pas][HelpIntfs][THelpManager.Create][293]
[FastMM4.pas][FastMM4][DebugGetMem][6000]
[HelpIntfs.pas][HelpIntfs][GetHelpSystem][274]
[system.pas][System][@NewAnsiString][11530]
[Forms.pas][Forms][TApplication.ValidateHelpSystem][7109]

[WinHelpViewer.pas][WinHelpViewer][initialization][655]
[system.pas][System][InitUnits][10548]
[system.pas][System][@StartLib][10710]

Dafür hab ich die Critical Section gefunden und elimiert. Ausserdem hatte sich doch noch ein IniFile-Object in einer anderen Unit versteckt. Hat leider nichts gebracht.

Die eingebundenen Units
uses Sysutils, IniFiles, Classes, DBTables, FileCtrl;

[smaug]

Ich hab das Ganze mal ausführlich debugt. Beim Beenden der DLL gibt's eine Access Violation.

Das letzte, was ich im Quellcode zu sehen kriege, ist DLLDetachCallback in DBTables. Im Assembler komm ich dann noch bis call idapi32.dbiEXT. Irgendwo da drinnen kracht's dann.