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.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: CORE-5537
URL: http://tracker.firebirdsql.org/browse/CORE-5537
Project: Firebird Core
Issue Type: Bug
Components: Engine
Affects Versions: 4.0 Alpha 1
Reporter: Pavel Zotov
Attachments:
unable-to-drop-database-in-ISQL-after-return-access-mode-to-RW.7z
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
