Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
firebird-automations opened this issue May 15, 2017 · 6 comments

Comments

@firebird-automations
Copy link
Collaborator

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

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

Attachment: unable-to-drop-database-in-ISQL-after-return-access-mode-to-RW.7z [ 13114 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

Attachment: child-FB-processes-still-exist-after-fb40cs_service-was-stopped.PNG [ 13115 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

assignee: Vlad Khorsun [ hvlad ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @hvlad

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

@firebird-automations
Copy link
Collaborator Author

Modified by: @hvlad

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 4.0 Alpha 1 [ 10731 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Resolved [ 5 ] => Resolved [ 5 ]

QA Status: No test => Covered by another test(s)

Test Details: See test for CORE4582

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants