MySQL Bugs: #52273: Dblqh::execLQHKEYREF can abort incorrect operation

Bug #52273	Dblqh::execLQHKEYREF can abort incorrect operation
Submitted:	22 Mar 2010 12:33	Modified:	29 Mar 2010 7:59
Reporter:	Jonas Oreland	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Cluster: Cluster (NDB) storage engine	Severity:	S3 (Non-critical)
Version:	mysql-5.1-telco-6.3	OS:	Any
Assigned to:	Jonas Oreland	CPU Architecture:	Any

Description:
Suppose the following sequence:
1) LQHKEYREQ (goes ok), alloc tcConnectptr = 0
2) Send LQHKEYREQ to backup replica(s)
3) ABORT (from TC), release tcConnectptr 0
4) LQHKEYREQ (from TC), WAIT_TUP
5) LQHKEYREF (from BACKUP, tcConnectptr 0)

In this case LQHKEYREF will start to abort incorrect operation!
("real" operation has already been aborted/recycled)

Note: Currently this problem is most likely harmless,
  but it complicates writing code in LQH

How to repeat:
run testBasic -n TupError
with patch for bug#52201 applied

Suggested fix:
use findTransaction in LQHKEYREF instead of tcConnectptr.i

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/103974

3162 Jonas Oreland	2010-03-22
      ndb - bug#52273
        Use findTransaction in LQHKEYREF to avoid weird race condtitions
          potentially leading to accessing recycled tcConnectPtr
          (which by itself most likely is harmless)

Pushed into 5.1.44-ndb-6.3.33 (revid:jonas@mysql.com-20100322123623-du2q1655e3umtrb4) (version source revid:jonas@mysql.com-20100322123303-km0qvr3txthjc44p) (merge vers: 5.1.44-ndb-6.3.33) (pib:16)

Pushed into 5.1.44-ndb-7.0.14 (revid:jonas@mysql.com-20100322123839-w1lmo3s0u6c0d8r4) (version source revid:jonas@mysql.com-20100322123839-w1lmo3s0u6c0d8r4) (merge vers: 5.1.44-ndb-7.0.14) (pib:16)

pushed to 6.3.33 and 7.0.14 and 7.1.3

Appears to be internal issue only, with no end-user changes to document.

Closed without further action.