Firebird 5.0.4 snapshot wrong error on shutdown failure

45 views
Skip to first unread message

Mark Rotteveel

unread,
Apr 8, 2026, 8:02:07 AMApr 8
to firebir...@googlegroups.com
I have a test in Jaybird that attempts to perform a transactional
shutdown (isc_spb_prp_deny_new_transactions) of the database without a
timeout, while a transaction is active. This test expects the shutdown
to fail with isc_shutfail (335544557)

This test passes against
* Firebird 5.0.3 (e.g. using firebird/firebird:5.0.3 and
ghcr.io/fdcastel/firebird:latest)
* the latest 6.0.0 snapshot (ghcr.io/fdcastel/firebird:6-snapshot)

However, it fails against the latest Firebird 5.0.4 snapshot when using
the Docker image ghcr.io/fdcastel/firebird:5-snapshot, and sometimes
(but not always!) against the latest Firebird 5.0.4 Windows x64 snapshot.

It does throw an exception (i.e. produce a statusvector), instead the
error is sent as text in the isc_info_svc_to_eof output.

The error written is:
```
database shutdown unsuccessful
-Secondary attachment - config data from DPB ignored
```

Which is the error that should be thrown (reported in the status
vector), but it isn't thrown.

The test is FBMaintenanceManagerTest.testTransactionalShutdown()
(https://github.com/FirebirdSQL/jaybird/blob/6decdaed076b8e420c91046219c4fee6f2770635/src/test/org/firebirdsql/management/FBMaintenanceManagerTest.java#L207).

Any idea what might be going on here?
--
Mark Rotteveel

Mark Rotteveel

unread,
Apr 8, 2026, 8:03:41 AMApr 8
to firebir...@googlegroups.com
On 08-04-2026 14:02, 'Mark Rotteveel' via firebird-devel wrote:
> It does throw an exception (i.e. produce a statusvector), instead the
> error is sent as text in the isc_info_svc_to_eof output.

That should have been: it does *not* throw an exception...

Mark
--
Mark Rotteveel

Mark Rotteveel

unread,
Apr 10, 2026, 3:41:23 AMApr 10
to firebir...@googlegroups.com
Anyone?

On 08-04-2026 14:02, 'Mark Rotteveel' via firebird-devel wrote:

Dmitry Yemanov

unread,
Apr 12, 2026, 2:10:44 AM (12 days ago) Apr 12
to firebir...@googlegroups.com
We had #8430/8431 fixed in 5.0.3 and master. Later postfix #8752 was
committed into both 5.0.4 and master. And then yet another postfix #8953
happened, but this time only into master. And it's about race
conditions, gfix and services -- looks like your case.

I've just backported the last postfix into v5, please re-test.


Dmitry

Mark Rotteveel

unread,
Apr 23, 2026, 4:44:35 AM (yesterday) Apr 23
to firebir...@googlegroups.com
On 12-04-2026 08:10, Dmitry Yemanov wrote:
> We had #8430/8431 fixed in 5.0.3 and master. Later postfix #8752 was
> committed into both 5.0.4 and master. And then yet another postfix #8953
> happened, but this time only into master. And it's about race
> conditions, gfix and services -- looks like your case.
>
> I've just backported the last postfix into v5, please re-test.


Sorry, I didn't have time to test it earlier, but it works fine now.

Mark

--
Mark Rotteveel
Reply all
Reply to author
Forward
0 new messages