An issue has been found when following scenario is performed in separate command windows ("cmd-..."):
- cmd-1: launch user-trace;
- cmd-2: async batch is launched with executing
CREATE DATABASE <path_to_db_<i> where <i> is some unique counter (e.g. 1,2, ...)
- cmd-3: async batch is launched with executing in loop
fbsvcmgr info_svr_db_info
Only 3.x running in SuperServer is affected. Could not reproduce same for 4.x ... 6.x or when change 3.x from SuperServer to Classic.
Original detailed description was provided by Alexey Kovyazin, see the file "AK_-_FB3_CREATE_DATABASE_TRACE_DEADLOCK.md" in attached .zip
The main reason (quote from .md): two engine threads take the same two locks in the opposite order:
----------------------------------------------------------------------------------------------------------------------
| Thread | Holds | Waits for |
|---------------------------------------------|------------------------------------|---------------------------------|
| CREATE DATABASE (JProvider::createDatabase) | dbb_sync of the new DB (exclusive) | databases_mutex |
| info_svr_db_info (JRD_enum_attachments) | databases_mutex | dbb_sync of the new DB (shared) |
----------------------------------------------------------------------------------------------------------------------
Initially this problem was found on Linux (probably, using AI).
I've checked it on Windows (used snapshot 3.0.15.33885-e92a839) and confirm that problem exists (at least same symptom appears: FB becomes hanging).
This is URL to the folder containing:
- two Windows batches which can be used to reproduce (one may take any of them):
batch_1_-_FB_3x_hangs_-_create_DB-and-svr_db_info.zip (main file there: crdb-srv-hang-main1.bat);
batch_2_-_FB_3x_hangs_-_create_DB-and-svr_db_info.zip (main file there: crdb-srv-hang-main2.bat).
Every batch will create sub-folder with name logs in the directory where it lives.
This sub-folder will be fulfilled with lot of temporary files, they are not deleted after test finish.
One need to adjust settings in each of these batches, namely:
set fbc=C:\FB\30SS
set /a db_count=250
set /a svc_cnt=600
(home directory of checked FB instance; number of databases to be created; number of iterations in the loop which will run fbsvcmgr info_svr_db_info).
It seems that ratio svc_cnt / db_count must be ~2.5 ... 3 in order to meet the problem during batch run.
It is assumed that FB instance accepts default password for SYSDBA.
- FB snapshot and used firebird.conf
- two sub-folders (
20260924_173338 and 20260924_200844) with dumps, stack-traces, lock-prints and aux files.
AK_-_FB3_CREATE_DATABASE_TRACE_DEADLOCK.md.zip
An issue has been found when following scenario is performed in separate command windows ("cmd-..."):
CREATE DATABASE <path_to_db_<i>where<i>is some unique counter (e.g. 1,2, ...)fbsvcmgr info_svr_db_infoOnly 3.x running in SuperServer is affected. Could not reproduce same for 4.x ... 6.x or when change 3.x from SuperServer to Classic.
Original detailed description was provided by Alexey Kovyazin, see the file "AK_-_FB3_CREATE_DATABASE_TRACE_DEADLOCK.md" in attached .zip
The main reason (quote from .md): two engine threads take the same two locks in the opposite order:
Initially this problem was found on Linux (probably, using AI).
I've checked it on Windows (used snapshot 3.0.15.33885-e92a839) and confirm that problem exists (at least same symptom appears: FB becomes hanging).
This is URL to the folder containing:
batch_1_-_FB_3x_hangs_-_create_DB-and-svr_db_info.zip(main file there:crdb-srv-hang-main1.bat);batch_2_-_FB_3x_hangs_-_create_DB-and-svr_db_info.zip(main file there:crdb-srv-hang-main2.bat).Every batch will create sub-folder with name
logsin the directory where it lives.This sub-folder will be fulfilled with lot of temporary files, they are not deleted after test finish.
One need to adjust settings in each of these batches, namely:
(home directory of checked FB instance; number of databases to be created; number of iterations in the loop which will run
fbsvcmgr info_svr_db_info).It seems that ratio svc_cnt / db_count must be ~2.5 ... 3 in order to meet the problem during batch run.
It is assumed that FB instance accepts default password for SYSDBA.
20260924_173338and20260924_200844) with dumps, stack-traces, lock-prints and aux files.AK_-_FB3_CREATE_DATABASE_TRACE_DEADLOCK.md.zip