AV in gds32.dll bei Zugriff über NT Service

[Christoph Schneider]

Ich habe einen NT-Service entwickelt, der auf eine Interbase DB via TCP/IP zugreift. Jetzt treten im Langzeitbetrieb verschiedene unverständliche Fehler auf, die mir keinen Sinn ergeben. Mitten im Betrieb stellte ich meist während kurzer Zeit (für einige wenige bis zu 100 Transaktionen in Serie) folgende Fehler fest:</BR>
- invalid statement handle 335544485</BR>
- invalid transaction handle 335544332</BR>
- unable to get generator value</BR>
- access violation in gds32.dll (Danach bleibt der Thread hängen)<BR>
Die Datenbank wird immer aus dem gleichen Thread über die IB-Object Komponenten zugegriffen. Der Server befindet sich auf der gleichen Maschine. Bis jetzt sind die Fehler auf mehreren Win2k Maschinen aufgetreten, konnten aber nie auf einer XP Installation gesichtet werden.

Wir verwenden folgende Konfiguration:<br>
Interbase Borland Open Source Version 6.0.1 sowie 6.0.2 von mers.com<br>
IBObject 4.2 Ib<br>
Delphi 6 SP2<br>
Win2k SP3<br>

Hat jemand ähnliche Erfahrungen mit einem Service und Interbase gemacht?

Besten Dank für Hinweise zur Klärung dieses ungewöhnlich schwierigen Falls.

[Chris Stengel]

Hi Christoph,<p>
wir verwenden auch Interbase Borland Open Source Version 6.0.1, und meine Services laufen seit 4 Monaten ohne Probleme auf Win2K. Allerdings C++ Builder und BDE. <br>
Bei der BDE brauchst Du fuer jeden DB Zugriff ein eigenes Session Objekt , eine eigenes DB Objekt und eine eigene Query. Ohne eigene Session und DB hatte ich (glaub ich ) mal einen aehnlichen Fehler.<br>
Vielleicht hilfts,<p>
CU Chri

[Günter Forster]

Hallo Christoph,

eini Threads bliebe bei mir hängen, nachdem ich Windows 2000 über das Internet mit dem Servicepack 3 beschenkt hatte.
Neu installiert mit SP2 alles ok, mit SP3 von CD auch alles ok. Nur die Rechner mit SP3 macht die Fehler.

Gruß Günte

[Thomas Steinmaurer]

Hallo Christoph,<br><br>
Dein Problem hör ich in dieser Art und Weise das erstemal. Ich würd auf jeden Fall mal folgende Dinge checken:<br><br>
- Läuft InterBase als Service oder als Applikation?<br>
- Existiert wirklich nur eine gds32.dll Version im Windows Suchpfad?<br>
- Ist Dein NT Service <b>multi-threaded</b>? Wenn ja, dann ist es notwendig aus jedem Thread per TCP/IP auf die Datenkbank zuzugreifen.<br>
- Verwendest Du InterBase Events, die in Deinem NT Service registriert werden?<br>
- Hast Du mehrere Netzwerkkarten in der Maschine, auf der InterBase läuft?<br>
- Jason bietet mit IBObjects 4 auch ein NT Service Framework an. Verwendest Du dieses Framework oder etwas eigenes?<br><br>
Gruss,<br>
Thoma

[Christoph Schneider]

Besten Dank für die zahlreichen Hinweise. Aufgrund der Hinweise möchte ich unsere Situation etwas präzisieren:<br>
<br>
- Damit der Zugriff auf Interbase aus einem Service sinnvoll ist, lassen wir auch Interbase als Service laufen.<br>
- Ich habe überprüft, dass sich nur eine Datei gds32.dll im System befindet.<br>
- Der Datenbankzugriff aus dem NT-Service erfolgt bei uns immer mittels TCP/IP Protokoll (soweit ich weiss, muss das auch so sein).<br>
- Wir haben mehrere Threads, welche einen Datenbankzugriff benötigen. Dabei hat jeder Thread eine eigene Session und Transaction.<br>
- In einem Thread benötigen wir auch IB-Events. Die Probleme stehen - soweit ich sehe - nicht im Zusammenhang mit diesem Event. (aber ich werde das mal Testen.<br>
- In den vier Maschinen, in dennen ich das Problem gesehen habe, war jeweils nur eine Netwerkkarte installiert. Es waren Netzwerkkarten unterschiedlicher Hersteller wie auch die Maschienen unterscheidliche Typen sind.<br>
- Unser Service basiert nicht auf dem Framework von IBObjects 4 sondern direkt auf dem Delphi Service Framework.<br>
- Ich sah dieses Problem auf Maschinen mit Win2k SP2 und SP3. Jetzt habe ich das Problem erstmals auch auf Win NT4.0 SP6 gesehen. Mit XP haben wir ebenfalls intensiv getestet, traffen den Effekt hingegen nie.<br>
- Unser Service läuft unter dem lokalen Systemkonto und der Datenaustausch zwischen Service und Desktop ist eingeschaltet. Der Service wird im moment manuell gestartet, später soll er automatisch gestartet werden<br>

Für weitere Hinweise bin ich dankbar.
Gruss Christop

[Thomas Steinmaurer]

Hallo Christoph,<br><br>
vielleicht noch 3 Dinge, die man in folgender Reihenfolge ausprobieren könnte:<br><br>
- In multi-threaded Anwendungen benötigt <b>jeder</b> Thread seine <b>eigene</b> Connection per TCP/IP (also: <i>localhost:c:\....</i> oder <i>server:c:\....</i>) zur Datenbank<br><br>
- Den NT-Service mal ohne IB-Events testen<br><br>
- Vielleicht sich doch Jason's IBO NT Service Framework ansehen<br><br>
Gruss,<br>
Thoma

[Christoph Schneider]

Hallo Thomas,

Besten Dank für Deine Hilfe. Zu den 3 Punkten:

- Wir setzen bereits für jede Session eine eigene TCP/IP Connection auf.<br>
- Ich habe versuchsweise das IB-Event nicht registriert und bekomme die selben Effekte.<br>
- Anstelle des IBO Service Framework zu verwenden, werde ich jetzt eine Test Applikation schreiben, welche den Body des Services in der selbenweise ausführt.

Gruss
Christop

[Thomas Steinmaurer]

Hallo Christoph,<br><br>
ich bin hartnäckig ;-). Du hattest zwar erwähnt, dass nur eine gds32.dll Version auf dem/den Rechner(n) existiert, für mich stellt sich dann noch die Frage, ob die gds32.dll Version auch mit der InterBase Server-Version übereinstimmt. D.h. es sollte z.B. sicherheitshalber nicht mit der Client-Version von 6.0.1 auf einen IB Server 6.0.2 zugegriffen werden. Borland supported absichtlich solche Installationen nicht, da hier ungeahnte Probleme auftauchen können!<br><br>
Gruss,<br>
Thoma

[Christoph Schneider]

Salü Thomas

Undurchsichtige Probleme kann man nur mit Hartnäckigkeit bezwingen - daher gilt mein Dank Deiner Unterstützung. Ich habe mal kurz die Produkte-Versions-Spalte in meinen interbase\bin Verzeichnis eingeschaltet. Der IBServer.exe wie auch alle anderen Exe und Dll's haben 6.0.2.0 (Mit Ausnahme der IBConsole.exe, welche noch 1.0.0.0 ist). Die Library unter C:\Winnt\system32\gds32.dll hat ebenfalls 6.0.2.0. Gibt es sonst noch eine Komponente, die ich überprüfen müsste?

Gruss Christop

[Thomas Steinmaurer]

Hallo Christoph,<br><br>
das sind alle notwendigen Dateien. Wenn auch noch nur eine gds32.dll auf dem Rechner existiert, dann kann man ein Installationsproblem mit ziemlicher Sicherheit ausschließen.<br><br>
Gruss,<br>
Thoma

[Christoph Schneider]

Das Problem ist mittlerweile gelöst und ich gebe hier gerne meine Erfahrungen in kurzform bekannt.

Die Client Library (gds32.dll) von IB 6.0 ist nicht Thread Save. Greifen mehrere Threads parallel (ohne Critical Section Sicherung) auf die selbe DB-Connection zu, treten genau die von mir beschriebenen Fehler auf. Diese Information ist mittlerweile Allgemeingut - ich fand zig Hinweise in diversen Newgroup dazu.

Bei mir lag aber keinen Concurrent Access vor und darum fand ich die Ursache lange nicht. Unterdessen habe ich durch längeres Fehlersuche festgestellt, dass auch die IB-Event-Registrierung Probleme bieten kann. Mein Prozess hat - aus Designgründen - relativ häufig IB Events registriert und deregistriert. Was genau der zu Grunde liegende Mechanismus ist, kann ich immer noch nicht genau beschreiben. Doch soviel steht fest: Werden IB-Events registriert, während Transaktion
am laufen und Datensets geöffnet sind, kanns (muss aber nicht) knallen. Ich vermute einen internen Zusammenhang zwischen Event-Registrierung und Concurrent Access. Jetzt werden bei mir die IB-Events nur noch einmal bei Service Start registriert - Damit läufts.

Noch ein Ausblick: Die Client-Library von IB6 und Firebird 1.5 sind Nicht Thread Save. Bei Interbase 7 ist dies jetzt erstmalig behoben. Es ist zu hoffen, das Firebird nachziehen wird.

Christoph Schneider
Schneider Infosystems AG
Switzerlan