Issue Details (XML | Word | Printable)

Key: CORE-5537
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Vlad Khorsun
Reporter: Pavel Zotov
Votes: 0
Watchers: 1

If you were logged in you would be able to see more operations.
Firebird Core

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.

Created: 14/May/17 09:25 PM   Updated: 22/May/17 09:46 AM
Component/s: Engine
Affects Version/s: 4.0 Alpha 1
Fix Version/s: 4.0 Alpha 1

File Attachments: 1. File unable-to-drop-database-in-ISQL-after-return-access-mode-to-RW.7z (2 kB)

Image Attachments:

1. child-FB-processes-still-exist-after-fb40cs_service-was-stopped.PNG
(19 kB)

QA Status: Covered by another test(s)
Test Details: See test for CORE-4582

 Description  « Hide
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 ..."


Issue was found when search for reason of failure of test for core-4582 (is occured only in Classic - for example, see here: ).

Reproduced on WI-T4.0.0.639, OS =Win XP.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Vlad Khorsun added a comment - 15/May/17 10:55 AM - edited
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