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

Hallo zusammen,

zuerst möchte ich allen die besten Weihnachts-Grüße übermitteln und hoffe,
dass Ihr diese Tage so angenehm verlebt, wie es Euren Wünschen entspricht.

Durch einige stressige Ereignisse musste ich mein Projekt "FB 2.5 nach FB 3.x pumpen" für einige
Zeit unterbrechen und bin es nun wieder angegangen.

In meiner Datenbank habe ich knapp 100 Tabellen deren Daten mit einem Script gepumpt und mit
einem anderen Script auf Korrektheit abgeglichen werden.

Bei einigen wenigen Tabellen brechen die Scripts scheinbar willkürlich ab, ohne irgendwelche Hinweise
auf die Ursache.

Im Browser steht dann die nichts sagende Meldung:
"Die Verbindung zum Server wurde zurückgesetzt, während die Seite geladen wurde."

Nach tagelangen intensiven erfolglosem Debugging und Recherchen bin ich nun durch Zufall,
beim Prüfen zu einer ganz anderen Frage, auf eine etwas aussage-fähige Fehlermeldung gestoßen
und im Ereignis-Protokoll vom Windows:
Name der fehlerhaften Anwendung: httpd.exe, Version: 2.4.54.0, Zeitstempel: 0x62b2cbd4
Name des fehlerhaften Moduls: fbclient.dll, Version: 3.0.10.33601, Zeitstempel: 0x629a57a6
Ausnahmecode: 0xc0000005
Fehleroffset: 0x000000000001be0f
ID des fehlerhaften Prozesses: 0x1b48
Startzeit der fehlerhaften Anwendung: 0x01d9194933533a26
Pfad der fehlerhaften Anwendung: D:\www\xampp\apache\bin\httpd.exe
Pfad des fehlerhaften Moduls: D:\WWW\Xampp\php\fbclient.dll
Berichtskennung: 3eeeb7a0-abdd-45c7-9216-976fe293489a
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:
"0xc0000005" ist laut Google der Fehler-Code für "Access violation".

Hat jemand evtl. eine Idee, wie man die Ursache für diesen Fehler
debuggen könnte ?

Danke und viele Grüße
bfuerchau
Beiträge: 485
Registriert: Mo 7. Mai 2018, 18:09
Kontaktdaten:

I.d.R. tritt dieser Fehler auf, wenn ein Objekt, auf das zugegriffen wird, zerstört wurde.
Ich frage mich, wieso bei deiner Aktion ein Web-Server (Appache?) im Spiel ist.
Da solche Migrationsprojekte durchaus etwas länger dauern können, sollte man diese nicht in einer Web-Umgebung durchführen.
Hier kann es durchaus z.B. durch Sitzungstimeouts dazu führen, dass eine Sitzung beendet wird, wenn sie nicht durch einen Web-Request verlängert wird.

Was du nun genau machst, geht aus deiner Beschreibung leider nicht hervor.
Du solltest aber auf jeden Fall die Scripte nicht in einer Web-Umgebung machen, ggf. das Pooling der Verbindung abschalten, so dass jede neue Aktion auch mit einer wirklich neuen Verbindung startet und keine Pool-Verbindung verwendet wird.

Je nach Sprache kann man per Try/Catch Fehler überwachen und (hoffentlich) im Stacktrace die Stelle genauer herausfinden.
vr2
Beiträge: 214
Registriert: Fr 13. Apr 2018, 00:13

Hamburgo hat geschrieben: Mo 26. Dez 2022, 20:45 zuerst möchte ich allen die besten Weihnachts-Grüße übermitteln und hoffe,
dass Ihr diese Tage so angenehm verlebt, wie es Euren Wünschen entspricht.
Danke! So ist es. Das wünsche ich Dir und der Runde hier auch.
In meiner Datenbank habe ich knapp 100 Tabellen deren Daten mit einem Script gepumpt und mit einem anderen Script auf Korrektheit abgeglichen werden.
Bei einigen wenigen Tabellen brechen die Scripts scheinbar willkürlich ab, ohne irgendwelche Hinweise auf die Ursache.
ok, das heißt zumindest, dass Dein Abgleichmechanismus über die Webanwendung grundsätzlich funktioniert. Also zb auch, dasss die eingesetzte fbclient.dll zu Deinem apache in xampp passt, und dass Du den richtigen php-Treiber am Start hast. Das ist schon mal eine ganze Menge.
Im Browser steht dann die nichts sagende Meldung:"Die Verbindung zum Server wurde zurückgesetzt, während die Seite geladen wurde."
Falls das wirklich nur der Timeout des Webservers war, setzt den in der php-ini mal zb auf 10 Minuten hoch, max-execution-time=600. Das kann es schon gewesen sein. Falls nicht: Siehst Du Fehler im php_error.log? Hast Du den Ort für das errorlog konfiguriert?, Sonst wird es nicht rausgeschrieben. Ich hab in der php.ini bspw

error_log="C:\xampp\php\logs\php_errors.log"

und da landen dann auch php-Fehler bzw auch durchgereichte des php-Firebird-Treibers und stack trace. Richte das mal ein, wenn Du es nicht konfiguriert hast, Du musst das Verzeichnis anlegen (hier: logs), xampp macht das nicht selber. Und dann provozier mal einen php-Fehler und check, dass in der php_errors.log was ankommt. Dann nochmal den DB-Abgleich der fraglichen Tabellen.

Viel Erfolg,

Volker
bfuerchau
Beiträge: 485
Registriert: Mo 7. Mai 2018, 18:09
Kontaktdaten:

Ich brauche für eine DB-Migration bei einem zeilenweisen Kopieren gerne schon mal 3-4 Stunden im Parallelmodus mit 4 "Workern", was mit einem Backup/Restore in ca. 90 Minuten erledigt wird (40GB-Datenbank).
In einer Nicht-Script-Umgebung wird das Ganze stabiler und vor allem schneller.

Ich habe nichts gegen PHP als echte Web-Umgebung;-).
Hamburgo
Beiträge: 125
Registriert: Di 28. Mai 2019, 17:28

Wichtig ist noch folgende Information:

Die eigentliche Aufgabe der Scripts, das Pumpen der Daten oder der Abgleich,
ob die Daten korrekt in der Ziel-DB angekommen sind, wird vom fbclient, soweit
ich das nachvollziehen kann, immer korrekt erfüllt.

Von der Standard-Einstellung her, verarbeiten beide Scripts immer Set's zu je
500 Records und wenn eine Tabelle mehr Records hat, dann wird ein Script
entsprechend häufig neu geladen (per Javascript ein Kick auf einen Submit-
Button) und liest das Folge-Set.

Das Verrückte ist ja, dass das Script problemlos weitläuft, wenn ich den Submit-
Button dann manuell klicke.

Die Access violation tritt immer nach Vollendung der eigentlichen Aufgabe ein,
wenn sie denn eintritt (passiert ja nur sporadisch).

Ich habe den Eindruck, dass FireBird am Ende eines Sets noch DB-interne Aufgaben
erledigt und dabei der Fehler auftritt.

Mit der Record-Menge pro Set hat das wohl nichts zu tun, da die Fehler auch auf-
treten, wenn ich die Sets auf 200 oder 100 reduziere.

Es mag für diese Aufgabe besser geeignete Umgebungen geben, als PHP unter
Apache auf einem Windows-Server.

Mein Problem ist nur; Ich habe und kann nichts anderes und mir wäre der Aufwand
zu hoch für diese einmalige Aktion noch etwas neues zu lernen.

Das ist ja nun auch nicht das grosse Drama. Der Zweck an sich wird ja erreicht,
läuft nur halt nicht voll automatisch durch und erfordert hier und da mein manuelles
Nachhelfen / Eingreifen.

Wenn die Scripts durchlaufen würden, wäre es halt perfekter und würde Zeit sparen.
Hamburgo
Beiträge: 125
Registriert: Di 28. Mai 2019, 17:28

Die diversen Log-Dateien liefern leider nur sehr spärliche Informationen.

Eigentlich keine, ausser die Apache-Error.log.
[Mon Dec 26 18:31:06.999848 2022] [mpm_winnt:notice] [pid 11440:tid 412] AH00354: Child: Starting 1048 worker threads.
[Mon Dec 26 20:27:17.032154 2022] [mpm_winnt:notice] [pid 7320:tid 424] AH00428: Parent: child process 11440 exited with status 3221225477 -- Restarting.
Die 3221225477 aus der Restarting-Meldung ist nach meinem Google der dezimale Wert für hex '0xc0000005' = Access violation.

Irgendwelche Grenzen von Speicher oder Treads usw. die evtl. überschritten werden könnten,
halte ich als Grund für eher unwahrscheinlich, weil zum einen der Fehler auch auftritt, wenn ich
die Set-Menge drastisch reduziere und andere, teils sehr grosse Tabellen, problemlos durchlaufen.

Und jedes Script hat so seine eigenen Lieblings-Tabellen, wo der Fehler auftritt und die sind
zueinander nicht die selben.

FireBird selbst schreibt Nichts in seine Error.log.

Die Aufgabe der Scripts ist relativ leicht beschrieben:

1. Lese aus Quell-DB Records in ISO-8859-1 kovertiere die Daten nach UTF8 und mache einen Insert in die Ziel-DB.

2. Lese aus Quell-DB Records in ISO-8859-1 und denn dazugehörigen Record aus der Ziel-DB in UTF8
und prüfe ob alle Daten identisch sind und die CharSet-Konvertierung geklappt hat.

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

Ich habe mir speziell auch nochmals die php_error.log angeschaut.

Da steht nichts drin, was für mich auch logisch ist, weil innerhalb von PHP
ja alles rund läuft.

Der Fehler entsteht ja, wenn die httpd.exe von Apache die fbcliend.dll startet und
die einen Fehler produziert und davon merkt php natürlich nichts.

Der Apache macht laut Error.log blitzschnell ein Restarting und deshalb kann FireFox
ja diese nichts sagende Meldung bei PHP loswerden und wird angezeigt.

Meine Standard-DB-Aktionen werden alle in TRY / CATCH-Blöcken ausgeliefert.

Wie gesagt, mein Eindruck ist, dass der Fehler nicht durch eine meiner
eigentlichen DB-Operationen geschieht, sondern im Nachgang, nachdem
alle meine DB-Aktionen pro Set schon final durch sind.

Indiz hierfür:
Nach jedem Set schreibe ich Protokoll-Informationen per fwrite in eine
simple Text-Datei und das immer erfolgreich.

Nach dem fclose sende ich an FireBird kein einziges Kommando mehr,
sondern klicke nur noch per Javascript auf den Submit-Button.

Und trotzdem scheint noch für die httpd.exe von Apache ein Grund
vorzuliegen die fbclient.dll starten zu müssen und das geht in 80%
der Fälle gut und bei den anderen kommt es zu dieser Access violation.

Warum, keine Ahnung.
bfuerchau
Beiträge: 485
Registriert: Mo 7. Mai 2018, 18:09
Kontaktdaten:

Versuche es noch mal in dem du bei den Connection-Properties den Connection-Pool abschaltest. Dadurch werden Verbindungen nicht gecached und bleiben, nachdem du fertig bist, auch nicht mehr offen.
Vorausgesetzt du machst auch immer einen Close auf die Verbindung.
Benutzeravatar
martin.koeditz
Beiträge: 443
Registriert: Sa 31. Mär 2018, 14:35

Ich glaube, das Abschalten des Connection-Pooling ist derzeit nicht möglich im PHP-Treiber.

Da der Apache sporadisch neustartet, vermute ich tatsächlich einen Crash, womit die laufende Verbindung dann gestoppt wird.
Kannst du mal eine etwas ältere fbclient.dll probieren? Welche php_interbase.dll bzw. php_firebird.dll nutzt du? Und welche PHP-Version?

Gruß
Martin
Martin Köditz
it & synergy GmbH
Hamburgo
Beiträge: 125
Registriert: Di 28. Mai 2019, 17:28

bei mir läuft:

Apache/2.4.54 (Win64) OpenSSL/1.1.1p PHP/8.1.10

php_8.1.0-interbase-3.0.0-win-x64-ts.dll
Antworten