Programm friert bei Open ein -> Fehler in gds32.dll

[RSE]

Delphi 5

Hallo,

der Fehler tritt unregelmäßig und unabhängig vom ausgeführten SQL an verschiedenen Stellen im Programm auf. Das Bild ist immer das gleiche: Zugriffsverletzung in CharUpperBuffA [2] während Query.Open [1] -> Query wird freigegeben [3] und das Programm hängt bei WaitForMultipleObjects [4].

Delphi-Quellcode:

  Query := TIBOQuery.Create(IB_Connection);
  try
    Query.IB_Connection := IB_Connection;
    Query.KeyLinksAutoDefine := GetEditableSelectResult;
    Query.RequestLive := GetEditableSelectResult;
    Query.SQL.Append(SQL);
    try
      Query.Open; // [1]
    except
      on E:Exception do
      begin
        Log('Fehler beim Öffnen der Query'#13#13 +
          'Fehlermeldung:'#13 + E.Message + #13#13 +
          'Fehlerverursachendes SQL:'#13 + Query.SQL.CommaText);
        raise; // Ausführung der Prozedur trotzdem abbrechen, Query freigeben
      end;
    end;
    try
      // Tue Was
    finally
      Query.Close;
    end;
  finally
    Query.Free; // [3] hier hängt er sich auf - siehe Callstack
  end;

Code:

7c91df48 +00a ntdll.dll                                    NtWaitForMultipleObjects           [4]
7c80958a +000 kernel32.dll                                 WaitForMultipleObjectsEx
7c80a110 +013 kernel32.dll                                 WaitForMultipleObjects
40547176 +003 gds32.dll                                    gds__thread_enter
40543b85 +065 gds32.dll                                    isc_dsql_free_statement
00522e77 +107 CCCClient.exe IB_Components                  TIB_Statement.SysUnprepare
005220b5 +065 CCCClient.exe IB_Components                  TIB_Statement.SysDeallocate
00521484 +030 CCCClient.exe IB_Components                  TIB_Statement.Unprepare
0055144f +01b CCCClient.exe IBDataset                      TIBODataset.Unprepare
005509a4 +014 CCCClient.exe IBDataset                      TIBODataset.Destroy                [3]
00403a5c +008 CCCClient.exe System               3530   +4 TObject.Free
00d55017 +137 CCCClient.exe CZ_Lib                351  +33 ExecuteSQL
0040423a +02a CCCClient.exe System               4715  +15 @HandleFinally
7c93ab7c +103 ntdll.dll                                    RtlUnwind
004041b6 +12e CCCClient.exe System               4654 +141 @HandleOnException
7c91e485 +009 ntdll.dll                                    KiUserExceptionDispatcher
7e36aebf +080 user32.dll                                   CharUpperBuffA                     [2]
40542ddb +16e gds32.dll                                    isc_dsql_execute2_m
40542bda +183 gds32.dll                                    isc_dsql_execute2
40542a4e +01a gds32.dll                                    isc_dsql_execute
00523ff0 +050 CCCClient.exe IB_Components                  TIB_Statement.API_Execute
00529d7d +005 CCCClient.exe IB_Components                  TIB_Dataset.SysExecSelect
00523219 +071 CCCClient.exe IB_Components                  TIB_Statement.SysExecStatement
00522f90 +098 CCCClient.exe IB_Components                  TIB_Statement.SysExecute
00529b98 +060 CCCClient.exe IB_Components                  TIB_Dataset.SysExecute
0052955f +10b CCCClient.exe IB_Components                  TIB_Dataset.SysOpen
0052919c +048 CCCClient.exe IB_Components                  TIB_Dataset.Open
00552798 +13c CCCClient.exe IBDataset                      TIBODataset.InternalOpen
004d1c9e +022 CCCClient.exe Db                   8260   +2 TDataSet.DoInternalOpen
004d1d6e +02e CCCClient.exe Db                   8289   +4 TDataSet.OpenCursor
004d1c09 +05d CCCClient.exe Db                   8242  +12 TDataSet.SetActive
004d1a6a +00e CCCClient.exe Db                   8203   +1 TDataSet.Open                      [1]
00d54f66 +086 CCCClient.exe CZ_Lib                334  +16 ExecuteSQL

Ist euch so etwas schon einmal untergekommen? Was würdet ihr tun, um das zu verhindern? Das Programm wird in einem Callcenter benutzt während wir mit den Anrufern sprechen. Solche Hänger kommen mehrfach täglich vor. Ist natürlich ungünstig, wenn das mitten im Gespräch passiert...

[mkinzler]

Warum Append?
Besser

Delphi-Quellcode:

Query.SQL.Text

direkt setzen.

[RSE]

Korrekt! :roll: Hilft aber leider nicht bei der Problemlösung. :( Ich werde es trotzdem ändern. :wink:

[neo4a]

Weise Deinem Query eine explizite TIB_Transaction zu.

[RSE]

@neo4a:
Kannst du mich zu den Hintergründen deines Lösungsansatzes aufklären?

Soweit ich weiß, startet IBO eine Standardtransaktion, die überall verwendet wird, wo nicht explizit eine andere Transaktion angegeben wird. Aktuell verwenden wir nur diese Standardtransaktion und nutzen das AutoCommit-Feature von TIBODatabase. Die im ersten Post zitierte Prozedur wird immer dann verwendet, wenn ein SQL-Statement (kann auch eine Abfrage sein) nur an einer Stelle benötigt wird und sich somit keine eigene Query etc. im DM lohnt. Momentan bekommen wir damit den Stand der DB von all dem, was mittels Query.Post bestätigt wurde. Dieses Verhalten darf sich nicht ändern. Leider habe ich keine umfassenden Kenntnisse von Datenbanken, um die Auswirkungen einer eigenen Transaktion umfänglich abschätzen zu können. Ich kann mir aber z.B. vorstellen, dass das die Ausführungsgeschwindigkeit (merklich???) und evtl. Sichtbarkeiten von Änderungen beeinflusst. Letzteres darf wie gesagt nicht sein.

[neo4a]

In allen meinen AdHoc-Abfragen habe ich immer dieses Konstrukt verwendet:

Delphi-Quellcode:

  
aQuery := TIB_Query.Create(nil);
try
  with aQuery do 
  begin
    sql.text:=Format(' select acc_profil from t_lms_account where nr=%d for update ',[lms.accountnr]);
    ib_Connection  := dm.IB_TransactionDefault.IB_Connection;
    ib_transaction := dm.IB_TransactionDefault;
    open;
    Edit;
    FieldByName('acc_profil').AsString := aProfile.AsString;
    Post;
  end
finally
  aQuery.free;
end;

und bin damit einer frühen Empfehlung von Jason gefolgt. Im produktiven Einsatz seit 1998 ist bei mir der von Dir geschilderte Fehler nie aufgetreten.

Gleichwohl gibt es beim Einsatz von Firebird (meine Erfahrung bis V. 2.1) einige Fallstricke. Einer der Wesentlichen: Auf Server und Client muss immer die gleiche gds32.dll verwendet werden. Ich habe dazu diese Datei in das Programm-Verzeichnis gelegt, damit sie nicht durch andere Installationen überschrieben wird (da gab's mal z.B. eine populäre Telefon-CD). Damit sind einige "komische" Effekte aus der Anfangszeit verschwunden.

Zur Transaktion: Es gibt keinen Perfortmance-Verlust, da jede SQL-Abfrage ohnehin in einer Transaktion abläuft. Benutzt Du Isolation = tiCommitted, solltest Du auch kein Problem mit der Sichtbarkeit haben. IBO verwendet verschieden Timer, um Deadlocks zu lösen. Ich denke, dass bei Dir dieser Fall auftritt. Man sollte z.B. in jedem Formular, eine eigene Transaktions-Komponente verwenden.

Error-Handling: Habe ich zentral auf IB_Connection.OnError abgearbeitet und nicht pro Query.

[RSE]

@neo4a:
Danke für den ausführlichen Post! Da sind einige Lösungsansätze enthalten, die ich ab Montag mal der Reihe nach abarbeiten werde.

Zur Transaktion: Ich dachte an die Erstellung einer neuen Transaktion auf dem Server. Aber der Zeitbedarf dafür ist sicherlich wenn, dann nur im Hochleistungsbereich interessant.:wink:

Zitat:

Zitat von neo4a

IBO verwendet verschieden Timer, um Deadlocks zu lösen.

Heißt das, wenn ich vor Query.Free lange genug warte, dann löst sich der Deadlock von selbst bzw. tritt nicht auf? Das werde ich mal probieren - besser lange warten als ewig warten. :thumb:

Zitat:

Zitat von neo4a

Man sollte z.B. in jedem Formular, eine eigene Transaktions-Komponente verwenden.

Im Moment haben wir gar keine... Ich weiß aber, dass IBO da im Hintergrund was macht. Werde mich am Montag nochmal genauer damit beschäftigen, wenn ich die Zeit finde.

IB_Connection.OnError werde ich mir dann auch mal zu Gemüte führen.


Jetzt wünsche ich allen erst mal ein schönes Woe, ich melde mich auf alle Fälle nächste Woche wieder, wenn es Neues gibt.

[RSE]

Ich habe die Versionen der gds32.dll überprüft. Hier alle Versionen der beteiligten Komponenten (falls was fehlt bitte nachfragen!):

• Delphi 5
• IBO Version 3.4.Ce (TIBODataBase, TIBOQuery)
• gds32.dll Version 6.0.1.0 (in System32 auf WinXP, keine gds32.dll im Programmverzeichnis)
• InterBase Server 6.1 auf Linux

Ich habe versucht, die tatsächlich zur Laufzeit geladene gds32.dll herauszubekommen und zu prüfen. Das schlägt leider fehl, weil IBO 3.4 noch kein TIB_SessionBase.GDS_Handle hat - das ist im Quelltext auskommentiert - und EnumProcessModules - zum Durchsuchen aller geladener dlls - ist in Delphi 5 offenbar noch nicht bekannt gewesen.
Wir benutzen TIBODataBase.Isolation = tiCommitted und TIBODataBase.AutoCommit = True. Gibt es da irgendwelche bekannten Versionskonflikte?

Bzgl. der Transactions steht in der Hilfe folgendes:

Zitat:

Here are some hints for working with IB Objects transactions:
With IBO three conceptual aspects of transaction need to be considered. They are the physical transaction, the logical transaction and whether the transaction is explicit. Each has its own behavior and in many cases the behaviors overlap. Other factors, such as isolation, also affect the behaviors.

Physical Transactions
· IBO automatically takes care of starting the physical transaction. It is not necessary to start the physical transaction explicitly yourself.
· It is the physical transaction which needs to be kept as short as possible so that the server is not prevented from doing its garbage collection.
· It is where the settings that provide the isolation, lockwait, recversion, and so on, take effect.
· The physical transaction forms the foundation for the logical and explicit transactions.

Long Transactions
A physical transaction of long duration can lead to severe performance degradation and, eventually, a server crash if it is left for more than a day or so in a moderately active database environment. A high-volume database could show signs of degradation within a day.

End of the Physical Transaction
A physical transaction is ended when Commit[Retaining], Rollback[Retaining], Refresh() or Close is called. The same methods also end a logical unit of work and an explicit transaction.

Oldest Active Transaction (OAT) Management
OAT (Oldest Active Transaction) Management is IBO's set of automated features that close the physical transaction for you. Provided you avoid or carefully manage the cases where the OAT management is suspended, you will not have any problems with long physical transactions in your applications.

Here are the cases that prevent IBO from automatically advancing the OAT:
1. You are not using cached updates, AutoCommit is false and you post any change to the database.
This flags the transaction as active (tsActive). The OAT stuff is suspended whilst a transaction's state is tsActive. You must call Commit[Retaining], Rollback[Retaining], LosePoint, SavePoint or Refresh() to resolve the active state of the transaction and allow the OAT stuff to resume.
2. You are using PessimisticLocking and you have a row in dssEdit state.
In order to give duration to the lock, the transaction must be held open. As soon as the row is posted or cancelled, the lock ends, the former rules apply and OAT behavior resumes.
3. You use the tiConcurrency isolation level.
OAT will not advance, because tiConcurrency tells the server that you want a snapshot view of the database. If physical transactions were to able to come and go in order to advance the OAT, the snapshot view would be corrupted. Each time a new transaction is started with tiConcurrency you get a fresh view of the database because other user's committed changes become visible.
4. You have a SELECT statement that will return thousands of rows and you open it but don't fetch all the records.
This forces a cursor to be held open on the server until all the rows have been fetched. Eventually this situation would be overcome by the background fetching that begins taking place in order to free up the cursor. If you set the CommitAction to caInvalidateCursor then it will just get refreshed for you and there won't be a problem.

It is generally inadvisable to leave large datasets open where all records are not fetched in.
Be sure to get familiar with the TimeOutProps settings because it is possible there to ensure that the OAT advancement issues can be dealt with.

Logical Transactions
Consider a logical transaction to be the unit of work that the user is performing. IBO will automatically keep track of your logical transaction for you.
Implicit Logical Transaction
Use the TransactionIsActive property to determine whether you are in an implicit logical transaction.
· If AutoCommit is true, the implicit logical transaction will be limited to the duration of time that any dataset is in an edit state. As soon as it is posted, the transaction is auto-committed and the implicit logical transaction ends.
· If AutoCommit is false then the implicit logical transaction will start from the moment at which a dataset is put into an edit state and will persist after a change is posted. It will not finish until the transaction is ended by explicitly calling one of the methods to end it.
· If a dataset is cancelled and no other changes had been posted then the implicit logical transaction will be ended automatically.

Explicit Transactions
· An explicit transaction is initiated by calling the StartTransaction method. It will persist until one of the methods to end the unit of work is called.
· LosePoint and SavePoint does not end an explicit transaction.
· The InTransaction property is used exclusively to determine whether you are in an explicit transaction. It does not indicate the status of an implicit logical transaction or of the underlying physical transaction.
· AutoCommit=True behavior is suspended during an explicit transaction and all changes posted to the server remain in the transaction, i.e. they are not committed when a dataset's Post method is called.

AutoCommit
· Setting AutoCommit to True allows you to avoid taking explicit control of logical transactions. It will generate an immediate SavePoint when you activate the transaction by posting a change to a dataset, executing a DML statement, etc. Everything becomes committed on the server the moment it is executed. In these conditions, there is no logical transaction to worry about.
· If AutoCommit is false, you need to call LosePoint, SavePoint, CommitRetaining, Commit, RollbackRetaining, Rollback or Refresh() in order to process a unit of work. These methods all end the logical transaction whether it is implicit or explicit.

In der Hilfe zu TIB_Database (Superklasse von TIBODatabase) steht folgendes:

Zitat:

In the case where a statement's or dataset's IB_Connection property is not a TIB_Database class, and its IB_Transaction property is left blank, it will create its own internal transaction. If you made the choice to avoid working with simultaneous transactions, this behavior could give rise to the undesirable effect of having different statements and datasets being kept within different transaction contexts.

Ich würde da jetzt mal reininterpretieren, dass für jede Query bei Bedarf automatisch eine eigene Transaktion angelegt wird (von Edit bis Post). Seht ihr das genauso?

Ich werde folgende Konstruktion ausprobieren, in der Hoffnung, dass der Vorschlag mit den IBO-Timern Erfolg bringt und der Konflikt intern in einem anderen IBO-Thread provoziert wird:

Delphi-Quellcode:

  Query := TIBOQuery.Create(IB_Connection);
  try
    Query.IB_Connection := IB_Connection;
    Query.KeyLinksAutoDefine := GetEditableSelectResult;
    Query.RequestLive := GetEditableSelectResult;
    Query.SQL.Append(SQL);
    try
      Query.Open;
    except
      on E:Exception do
      begin
        Log('Fehler beim Öffnen der Query'#13#13 +
          'Fehlermeldung:'#13 + E.Message + #13#13 +
          'Fehlerverursachendes SQL:'#13 + Query.SQL.CommaText);
        // Hoffen, dass sich das Aufhängen bei der Freigabe mittels WaitForMultipleObjects durch vorheriges Warten erledigt
        for i := 300 downto 0 do // sollte ein paar Sekunden entsprechen
          Sleep(0); // verwirft den Rest der Zeitscheibe
        raise; // Ausführung der Prozedur trotzdem abbrechen, Query freigeben
      end;
    end;
    try
      // Tue Was
    finally
      Query.Close;
    end;
  finally
    Query.Free;
  end;

[neo4a]

Server- und IBO-Version sind sehr alt. Ich kenne nicht Dein Budget, aber zumindest für den Server gibt es mit Firebird eine gute Alternative. Ich habe zu Zeiten von IBO 3.X mit Firebird 1.03 keine Probleme gehabt.

Das "Einfrieren" sieht mir - wie gesagt - ganz nach einem Deathlock aus. Du kannst dieses Verhalten recht leicht nachstellen, indem Du einen Datensatz mit einem SQL-Tool (z.B. IB_SQL) editierst und die Transaktion nicht beendest. Dann gehst Du mit Deiner App (sofern sie in dem Alter noch gehen kann) auf diesen Datensatz und tust, was Du tun willst. Überprüfe, ob da was einfriert.

Kannst Du so das Verhalten Deiner App reproduzieren, dann kann man Lösungen suchen, alles andere ist Mutmaßung und führt eigentlich zu nichts.

[RSE]

Zitat:

Zitat von neo4a (Beitrag 1129647)

Server- und IBO-Version sind sehr alt.

Da stimme ich völlig mit dir überein. Da das Programm aber noch viel schwerfälliger ist, als die DB-Version alt, und die Programmierkapazitäten (genau wie die im DB-Management) äußerst knapp sind, muss ich wohl noch ´ne Weile damit auskommen... :(

Zitat:

Zitat von neo4a (Beitrag 1129647)

Das "Einfrieren" sieht mir - wie gesagt - ganz nach einem Deathlock aus. Du kannst dieses Verhalten recht leicht nachstellen, indem Du einen Datensatz mit einem SQL-Tool (z.B. IB_SQL) editierst und die Transaktion nicht beendest. Dann gehst Du mit Deiner App (sofern sie in dem Alter noch gehen kann) auf diesen Datensatz und tust, was Du tun willst. Überprüfe, ob da was einfriert.

Kannst Du so das Verhalten Deiner App reproduzieren, dann kann man Lösungen suchen, alles andere ist Mutmaßung und führt eigentlich zu nichts.

Das ist eine Idee. Ich bin allerdings sehr skeptisch, ob das glücken wird, weil:

1. Die Abfragen im Programm, die den Fehler verursachen sind simple SELECT-Abfragen, keine Updates etc.
2. Wäre es ein Deadlock auf der DB aufgrund von Zugriffsbeschränkungen durch andere Transaktionen, dann sollte es trotzdem keine Zugriffsverletzung in Modul gds32.dll geben

Ich werde morgen berichten, was dabei herausgekommen ist.

Gehen wir mal davon aus, dass es sich tatsächlich um einen Bug in der DLL handelt. Wir setzen hier IBExpert ein. Dort gibt es eine gds32.dll von 2004 (Version 1.5.2.4731 für Firebird 1.5), die offenbar für die Verbindung zu unserem Interbase 6.1 verwendet wird, wenn ich die IBExpert-DB-Einstellungen richtig lese. Meinst du es ist eine gute Idee diese neuere dll testweise auf den Clients zu verwenden, auf denen unser Programm läuft? IBExpert läuft sehr stabil auf unserem IB 6.1 Server.