Bug #81907 TC timetracking can crash due to not initialised timer

• Submitted: 17 Jun 2016 11:43
• Modified: 27 Jun 2016 14:54
• Reporter: Mikael Ronström
• Status: Closed
• Category: MySQL Cluster: Cluster (NDB) storage engine
• Severity: S2 (Serious)
• Version: 7.5.3
• OS: Any
• CPU Architecture: Any

[17 Jun 2016 11:43] Mikael Ronström

Description:
We track time from sending SCAN_FRAGREQ to receiving SCAN_FRAGCONF.
The assumption was that SCAN_FRAGCONF can only come after sending SCAN_FRAGREQ or SCAN_NEXTREQ.
However this is not so, after sending SCAN_FRAGCONF LQH can send SCAN_FRAGCONF again immediately
after reporting that scan is closed.

How to repeat:
Run autotest suite in debug mode

Suggested fix:
Check that timer is valid before using it

[27 Jun 2016 14:54] Jon Stephens

Documented fix in the NDB 7.5.3 changelog as follows:

    When tracking time elapsed from sending a SCAN_FRAGREQ
    signal to receiving a corresponding SCAN_FRAGCONF, the assumption
    was made in the DBTC kernel block that a SCAN_FRAGCONF can occur only
    after sending SCAN_FRAGREQ or SCAN_NEXTREQ, which is not the case: It
    it is actually possible that a local query handler can, immediately
    after sending a SCAN_FRAGCONF, send an additional SCAN_FRAGCONF upon
    reporting that the scan is closed. This is fixed by ensuring that the
    timer is initialized each time before use.

Closed.