Bug #73842 Make signal dump in trace files always start from latest signal
Submitted: 8 Sep 2014 23:14 Modified: 18 Sep 2014 10:33
Reporter: Mauritz Sundell Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Cluster: Cluster (NDB) storage engine Severity:S3 (Non-critical)
Version:7.1 OS:Any
Assigned to: CPU Architecture:Any

[8 Sep 2014 23:14] Mauritz Sundell
Description:
For multithreaded data nodes there some some threads communicate very seldom, very old signals can be in top of signal buffer s used.  Since the signal dumper calculates the latest signal id from what it sees in signal buffers, these old signals can have signal id that looks newest.

How to repeat:
Seen in customer logs.

Suggested fix:
Keep signal id counter in thread state and use that in signal dump instead of calculate the latest signal id from signal buffers.
[18 Sep 2014 10:33] Jon Stephens
Thank you for your bug report. This issue has been committed to our source repository of that product and will be incorporated into the next release.

Fix for this bug documented as follows in the NDB 7.1.33, 7.2.18, and 7.3.7 changelogs:

    For multithreaded data nodes, some threads do communicate often,
    with the result that very old signals can remain at the top of
    the signal buffers. When performing a thread trace, the signal
    dumper calculated the latest signal ID from what it found in the
    signal buffers, which meant that these old signals could be
    erroneously counted as the newest ones. Now the signal ID
    counter is kept as part of the thread state, and it is this
    value that is used when dumping signals for trace files.
      
Closed.

If necessary, you can access the source repository and build the latest available version, including the bug fix. More information about accessing the source trees is available at

    http://dev.mysql.com/doc/en/installing-source.html