Subject lock conversion denied/lock denied bug still exists in FB 2.5.3

[#CORE-2848] "lock conversion denied" or "lock denied" error - Firebird RDBMS Issue Tracker

Same or similar bug still exists in 2.5.3 release and frequently (1-10 times per day) appears in our production environment, even after backup/restore with 2.5.3

Conditions to reproduce:

*) win2008 x64 (in production also appears on 2003 32bit windows, but much less frequently)

*) 32-bit classic server

*) 1 writer thread, quasi-randomly updating short (~1000 records) table, causing heavy record fragmentation, commit one time per 15 seconds. 

To repeat production db access patterns I have tried to force fragmentation by switching between random and non-random data generation for fields. 

Also, bug probability appears to depend on record size.

*) 10-20 reader threads, reading same table, different isolation levels and read/write modes, commit one time per 15 seconds. Not sure if this really needed.

*) every 10 minutes there is a scheduled task to perform sweep on database. In production this service task scheduled one time per day.

*) every minute all connections are closed and opened again. 

Approximately 1-5 time per day writer thread connection returns an error:


page 34512, page type 5 lock denied.

with corresponding message in firebird.log:
WIN200864   Wed Nov 12 21:21:27 2014
    Database: gcstress
    page 34512, page type 5 lock denied (216)

or other similar messages

WIN200864   Wed Nov 12 08:25:36 2014

    Database: gcstress

    page 256, page type 4 lock conversion denied (215)

(page 256 is primary pointer page for heavily updated table)

I have been able to reproduce it on test database and have database file, lock print and failing fb_inet_server process debug dump (all when fb_inet_server stopped on debugger breakpoint on corresponding fb_msg_format calls in cch.cpp/lock_buffer)


Should I go to issue tracker and post duplicate of this message there?

Also whom I should send debug dumps (400 mb archive link)