Access violation: fbclient.dll Version: 3.0.10.33601 Apache 2.4 unter Windows

Themen rund um den praktischen Einsatz von Firebird. Fragen zu SQL, Performance, Datenbankstrukturen, etc.

Moderator: thorben.braun

Hamburgo
Beiträge: 125
Registriert: Di 28. Mai 2019, 17:28

fbclient.dll: WI-V6.3.4.33054 Firebird 3.0

läuft wesentlich stabiler, ob sie durchläuft kann ich noch nicht sagen.
Hamburgo
Beiträge: 125
Registriert: Di 28. Mai 2019, 17:28

fbclient.dll: WI-V6.3.4.33054 Firebird 3.0

Update:
Diese DLL hat die Tabelle, die bisher die größten Probleme bereitet
hat, problem-los geschafft und läuft bisher auch automatisch weiter,
egal ob ich Sets 100 oder 500 einstelle.

Somit ist Martin wohl auf der richtigen Fährte.

Bedeutet wohl, dass die aktuelle V3.0.10.33601 einen Bug hat oder ?
Benutzeravatar
martin.koeditz
Beiträge: 443
Registriert: Sa 31. Mär 2018, 14:35

Guten Morgen Hamburgo,

es muss nicht unbedingt die fbclient.dll sein. Aber irgendwas im Zusammenhang mit dieser scheint ja das Problem zu verursachen. Gibt es einen Weg das Problem nachzustellen?

Gruß
Martin
Martin Köditz
it & synergy GmbH
vr2
Beiträge: 214
Registriert: Fr 13. Apr 2018, 00:13

Hamburgo, hast Du irgendwelche aktuelleren Meldungen in php_error.log, muss nicht von Deinen Tests sein, aber ist sicher, dass sie genutzt wird? Denn Firebird-Treiber-Fehlermeldungen kommen normalerweise auch da rein.

Gruß Volker
Hamburgo
Beiträge: 125
Registriert: Di 28. Mai 2019, 17:28

Hallo Volker,

ja, die php_error.log ist korrekt konfiguriert.

Mein 2. Script verursacht beim Start immer ein Warning und das ist in der Log-Datei
immer zu sehen.
Hamburgo
Beiträge: 125
Registriert: Di 28. Mai 2019, 17:28

Hallo Martin,

aktuell laufen die Scripts unter Localhost.

Es wäre aber auch möglich diese unter einer Web-Domain public laufen zu
lassen.

Nur habe ich keine Idee, was das helfen sollte.

Die jeweiligen Browser, egal ob FireFox, Chrome, Opera usw. bringen in der
Sache selbst ihre für das Problem entsprechende Meldung in den Developer-
Tools.

Einzig der FireFox bringt obendrauf eine Meldung im Browser-Fenster selbst.

Alle Meldungen kommen zu demselben Ergebnis, dass der Server, also Apache,
die Verbindung/Connection zurückgesetzt hat.

Der Apache selbst, also die httpd.exe, läuft ja stabil weiter und produziert KEINEN
Fehler.

Er reagiert nur mit einem "Restarting!" auf die "Access violation", die ihm von der
fbclient.dll zurückgeliefert wird.

Da die erneute Benutzung der fbclient.dll nicht in Verbindung zu einer von meinem
Script abgesetzten DB-Operation steht, weil die schon weit vor der "Access violation"
erfolgreich verarbeitet wurden, habe ich keine Idee wie man es anstellen könnte die
Entstehung der "Access violation" beobachten zu können.

Ich weiss ja nicht einmal warum die fbclient.dll überhaupt nochmals angesprochen
wird.

Das scheint ja wohl auf Grund von internen Erfordernissen von FireBird selbst zu
geschehen.

Nach dem fclose auf meine interne Protokoll-Datei, klicke ich ja nur noch per
javascript auf den Submit-Button.

Ziemlich sicher steht auch fest, dass die fbclient.dll in dem Moment nochmals
angesprochen wird, wenn die JavaScript-Funktion aufgerufen wird, die auf den
Submit-Button klicken soll.

Der Klick selbst findet nicht mehr statt.

Es hat weder geholfen vor den Click-Befehl einen Alert zu setzen, wodurch im
Normal-Fall das Script vor Click gewollt hängen bleibt, noch den Click-Befehl
zu deaktivieren.

Die "Access violation" kam auf jeden Fall.

Es half auch nichts das PHP-Script per Exit vor oder direkt nach dem Schreiben
meiner internen Protokoll-Datei abzubrechen.

Die "Access violation" kam trotzdem.

Habe ich das Exit vor der Protokoll-Datei gesetzt, war das Ergebnis nur, dass
diese logischerweise nicht geschrieben wurde.

Habe ich das Exit nach der Protokoll-Datei gesetzt oder ganz weggelassen,
war das Ergebnis dasselbe.

Dir Protokoll-Datei wurde korrekt geschrieben und dann ist das Script abgekackt.

Auch ein Deaktivieren des Javascript-Snippets, dass die Submit-Button-Click-
Aktion anstößt, also einfach das Script nach dem Record-Set nicht neu zu
laden, hat nicht geholfen.

Fakt ist: Der unkontrollierte erneute Aufruf der fbclient.dll erfolgt auf jeden
Fall am ENDE des Scripts, egal wie dieses Ende gestaltet wird.

Es hat auch nichts geholfen, dass ich alle Javascript-Aktionen in $(document).ready
Container gepackt habe, diese also erst ausgeführt werden, wenn das DOM formal
korrekt komplett geladen ist.

Wenn Du allerdings noch eine Idee hast, wie man in das Problem eine bessere
Transparenz hineinbekommt, dann gerne, immer her damit.

Ich habe keine Idee mehr, wie man da einhaken könnte.

Komisch ist für mich jedenfalls, dass FireBird selbst nichts in seine eigene Error.log schreibt.
Hamburgo
Beiträge: 125
Registriert: Di 28. Mai 2019, 17:28

fbclient.dll: WI-V6.3.4.33054 Firebird 3.0

Finales Ergebnis:

Mit der oben genannten DLL läuft alles, wie es soll voll automatisch
problem-frei durch.
Antworten