You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Assign DB access_mode to RW (by using gfix or fbsvcmgr) leads FB 4.0 Classic to create new firebird-process on every such attempt. Stopping FB Classic service does not drop these ("child") FB processes. [CORE5537]
#5805
0. Ensure that you have utility 'pslist' from SysInternals package to list FB processes (for those who still use Win XP :))
1. Stop all running FB instances
2. Launch only one: FB 4.0, in Classic mode.
3. Open batch (from attached .7z) in editor and correct following env. variables:
set fbc=C:\MIX\firebird\FB40Cs\ --- folder where binaries for FB 4.0 live;
set dbn=C:\MIX\firebird\QA\fbt-repo\tmp\c4582.fdb --- path and name of test database
4. Run batch with logging its output (STDERR & STDOUT) to file-1.txt
5. Repeat "4." several times with logging to another files.
Output from 1st file will start with these lines:
Check firebird processes at the START point of test:
----------------------------------------------------
firebird 920 8 5 80 1892 0:00:00.062 0:00:06.125
----------------------------------------------------
....
- and ends with these:
Check firebird processes at the FINAL point of test:
----------------------------------------------------
firebird 920 8 6 85 1908 0:00:00.062 0:00:22.765
firebird 2140 8 2 126 12032 0:00:00.125 0:00:15.156
----------------------------------------------------
So, we have 2 (two) FB processes instead of one.
Every subsequent launches of batch will add "+1" to the number of FB processes.
If we stop FB service than all these "child" processes will NOT be removed from tasks list - they just become "independent" and do nothing, but still present there.
Every launch of batch will issue:
SQL> Statement failed, SQLSTATE = 40001
lock time-out on wait transaction
-object C:\MIX\FIREBIRD\QA\FBT-REPO\TMP\C4582.FDB is in use
-- as reply on attempt to drop database.
This occurs ONLY when we try to revert DB in read-write access mode.
Note also that subseq. launch of batch _can_ successfully drop database by using OS command 'del <file>' - but this can relate to Windows specific. Lock-print output _show_ data, it's NOT empty when we finish command 'gfix -mode read_write ..."
There is two issues in this ticket
1. Bugcheck when mode is changed to read-write
engine13\.dll\!ERR\_bugcheck\(number=266, file=0x000007fee48177d8, line=4813\) Line 75 C\+\+
engine13\.dll\!write\_page\(tdbb=0x000000000b4dea20, bdb=0x000000000c0128f0, status=0x000000000b4de9f0, inAst=false\) Line 4815 C\+\+
engine13\.dll\!write\_buffer\(tdbb=0x000000000b4dea20, bdb=0x000000000c0128f0, page=\{\.\.\.\}, write\_thru=false, status=0x000000000b4de9f0, write\_this\_page=true\) Line 4754 C\+\+
engine13\.dll\!CCH\_release\(tdbb=0x000000000b4dea20, window=0x000000000b4de898, release\_tail=false\) Line 1841 C\+\+
engine13\.dll\!CCH\_RELEASE\(tdbb=0x000000000b4dea20, window=0x000000000b4de898\) Line 99 C\+\+
engine13\.dll\!TRA\_update\_counters\(tdbb=0x000000000b4dea20, dbb=0x000000000a0831d0\) Line 857 C\+\+
engine13\.dll\!JRD\_shutdown\_database\(dbb=0x000000000a0831d0, flags=3\) Line 6797 C\+\+
engine13\.dll\!purge\_attachment\(tdbb=0x000000000b4df180, sAtt=0x000000000a85cb18, flags=2\) Line 7226 C\+\+
engine13\.dll\!Jrd::JAttachment::freeEngineData\(user\_status=0x000000000b4df408, forceFree=false\) Line 2944 C\+\+
engine13\.dll\!Jrd::JAttachment::detach\(user\_status=0x000000000b4df408\) Line 2895 C\+\+
Ther reason for bugcheck is that fb4 run transactions when attached to the database and dbb->dbb_oldest_active is advances
while dbb->dbb_next_transaction is not.
In fb3 PAG_header is called after getUserInfo and reset dbb counters (this fb3 is not affected) but in fb4 the order of operations is different.
2. Due to bugcheck at JRD_shutdown_database not all references to the engine provider is released and process shutdown
waits forever in PluginManager::waitForType(IPluginManager::TYPE_PROVIDER)
I'll fix the reason for the bugcheck and leave second issue for the another task
Submitted by: @pavel-zotov
Attachments:
unable-to-drop-database-in-ISQL-after-return-access-mode-to-RW.7z
child-FB-processes-still-exist-after-fb40cs_service-was-stopped.PNG
0. Ensure that you have utility 'pslist' from SysInternals package to list FB processes (for those who still use Win XP :))
1. Stop all running FB instances
2. Launch only one: FB 4.0, in Classic mode.
3. Open batch (from attached .7z) in editor and correct following env. variables:
set fbc=C:\MIX\firebird\FB40Cs\ --- folder where binaries for FB 4.0 live;
set dbn=C:\MIX\firebird\QA\fbt-repo\tmp\c4582.fdb --- path and name of test database
4. Run batch with logging its output (STDERR & STDOUT) to file-1.txt
5. Repeat "4." several times with logging to another files.
Output from 1st file will start with these lines:
Check firebird processes at the START point of test:
----------------------------------------------------
firebird 920 8 5 80 1892 0:00:00.062 0:00:06.125
----------------------------------------------------
....
- and ends with these:
Check firebird processes at the FINAL point of test:
----------------------------------------------------
firebird 920 8 6 85 1908 0:00:00.062 0:00:22.765
firebird 2140 8 2 126 12032 0:00:00.125 0:00:15.156
----------------------------------------------------
So, we have 2 (two) FB processes instead of one.
Every subsequent launches of batch will add "+1" to the number of FB processes.
If we stop FB service than all these "child" processes will NOT be removed from tasks list - they just become "independent" and do nothing, but still present there.
Every launch of batch will issue:
SQL> Statement failed, SQLSTATE = 40001
lock time-out on wait transaction
-object C:\MIX\FIREBIRD\QA\FBT-REPO\TMP\C4582.FDB is in use
-- as reply on attempt to drop database.
This occurs ONLY when we try to revert DB in read-write access mode.
Note also that subseq. launch of batch _can_ successfully drop database by using OS command 'del <file>' - but this can relate to Windows specific. Lock-print output _show_ data, it's NOT empty when we finish command 'gfix -mode read_write ..."
PS.
Issue was found when search for reason of failure of test for core-4582 (is occured only in Classic - for example, see here: http://web.firebirdsql.org/download/prerelease/results/4.0.0.639/ ).
Reproduced on WI-T4.0.0.639, OS =Win XP.
Commits: 425192a
====== Test Details ======
See test for CORE4582
The text was updated successfully, but these errors were encountered: