Attachment and transactions ID's derived from values stored on header page.
In case of read-only database this values keeps in-memory and incremented as needed.
isc_database_info call leads to re-reading of header page and re-reading in-memory counterrs for next attachment and transaction IDs.
Therefore it is possible that some attachments\transactions will have the same ID's as some older attachments\transactions.
It leads to waiting of new attachment\transaction for the end of existing attachment\transaction with the same ID.
When waiting for attachment lock, global mutex is locked and old attachment can't even complete own disconnect and release attachment lock.
So, we have an endless deadlock. This is (deadlock) true for SuperServer. For Classic Server we will observe hang of some new attachment\transaction until existing attachment\transaction is alive.
v2.5 have no this bug as it derives new attachment\transaction ID from shared counter and it can't be reset by re-reading header page.