Issue Details (XML | Word | Printable)

Key: CORE-4372
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Vlad Khorsun
Reporter: Vlad Khorsun
Votes: 0
Watchers: 5
Operations

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

Deadlock is possible when two data pages contains record fragments pointing to each other

Created: 25/Mar/14 09:37 AM   Updated: 23/Sep/15 11:20 AM
Component/s: Engine
Affects Version/s: 2.1.0, 2.1.1, 2.1.2, 2.1.3, 2.5.0, 2.1.4, 2.5.1, 2.1.5, 2.5.2, 2.1.5 Update 1, 2.5.2 Update 1, 3.0 Alpha 1, 3.0 Alpha 2
Fix Version/s: 2.5.3, 3.0 Beta 1

Issue Links:
Relate
 

QA Status: Not enough information
Test Details: Need hint about scipt that prepares data with adjusting on database pages exactly as described here.


 Description  « Hide
Below is typical case when deadlock happens.

Note, lock table dump and memory dump was produced (by custom build of FB 2.5) at moment when deadlock is detected by lock manager.
Therefore both dumps are consistent with each other.


First, look at lock table dump:

LOCK BLOCK 15127944
Series: 3, Parent: 26520, State: 3, size: 8 length: 8 data: 0
Key: 0001:2386725, Flags: 0x00, Pending request count: 2
Hash que (23): forward: 1109840, backward: 2404168
Requests (3): forward: 15467224, backward: 17397008
Request 15467224, Owner: 4605016, State: 3 (3), Flags: 0x100
Request 33823352, Owner: 1406720, State: 0 (6), Flags: 0x22
Request 17397008, Owner: 22445704, State: 0 (3), Flags: 0x22


LOCK BLOCK 34415560
Series: 3, Parent: 26520, State: 3, size: 8 length: 8 data: 0
Key: 0001:2386706, Flags: 0x00, Pending request count: 2
Hash que (17): forward: 1595232, backward: 1221992
Requests (3): forward: 28400464, backward: 32840696
Request 28400464, Owner: 22445704, State: 3 (3), Flags: 0x100
Request 15282984, Owner: 29728544, State: 0 (6), Flags: 0x22
Request 32840696, Owner: 4605016, State: 0 (3), Flags: 0x22

Here owners 22445704 and 4605016 owns locks 34415560 and 15127944 correspondingly and acquires others lock at the same time.
This is classical deadlock.
Note, despite of compatible lock requests, it can't be granted because of another non-compatible requests in high position in
pending request queue (by owners 1406720 and 29728544).

Lets look at memory dump to see how this happens:

a) owner 4605016 call DPM_fetch_fragment which call CCH_handoff (DP->DP)
  2386725 -> 2386706

b) owner 22445704 call DPM_fetch_fragment which call CCH_handoff (DP->DP)
  2386706 -> 2386725


Outcome of this deadlock is "lock denied" error.
Usually it have no problems other than abort of current user statement.


 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
There are no subversion log entries for this issue yet.