>gfix –validate –full

>any errors (also in firebird.log)?

The server have about 20 db’s, haven’t performed a validate full on each one of them.
At the moment Im assuming theres no corruption because all of our clients are fully operational and there are no incidents reported by them.

>Did you performed backup/restore process.

Yes all db’s were backed up in 2.5 and restored in 3

>Do you use any udf? also system udf?

We use quite a few udf’s , mosltly from freeAdhocUdf and some system ones.

If an UDF was the culprit of the crash, Im assuming it would always crash at a certain query or function call, is this safe to assume?

>Do you have enough free mem, free disk space also for temp files like sorting?

Yes I don’t think this firebird installation every got above 2gb of peak ram usage out of 10gb free

>Do you have recent Firebird version (which exactly) and also fbclient.dll version (if you use it or gds32.dll)

The latest stable firebird version 3.0.2 march/22

From what I can tell, we don’t use the client libraries (we do use for ibexpert but we rarely use ibexpert)

We are running apache with php 5.6 on linux machines, connecting to the windows firebird server.

The linux machines themselves have no firebird installation, only pure apache and php.

What I do know is that the php firebird extension was not updated to work with firebird 3.

One thing that I know that doesn’t work, for instance, are the new Boolean fields (we cannot use Boolean fields because php will not be able to read them).

So, while php continues to be my number one suspict here, I was unable to capture a single error log which I’m able to recreate the crash.

If php was crashing on a certain query, it would be trivial for me to get it from my logs (we log queries prior their execution) and recreate the crash.

So, not only that is not happening, but also I can’t seem to get crash dump logs as described initially.

This problem have been happening since day 1 of our new servers operating with firebird 3, about 5 months now.