Bug #107234 Failed list management in setNeighbourNode in mt.cpp

• Submitted: 7 May 2022 15:13
• Modified: 26 Oct 2023 9:25
• Reporter: Mikael Ronström
• Status: Won't fix
• Category: MySQL Cluster: Cluster (NDB) storage engine
• Severity: S3 (Non-critical)
• Version: 8.0.29
• OS: Any
• CPU Architecture: Any

[7 May 2022 15:13] Mikael Ronström

Description:
In setNeighbourNode we remove transporters from the list of transporters that are ready to send. The removed transporters are moving to become neighbour transporters.

However the removal function is supposed to remove it from a single linked list with first and last pointers. The update of the last pointer is missing and the previous pointer is supposed to be updated in the loop, but it is only initialised and not updated in the loop.

This leads to that a transporter in ready state is lost from the list and this leads to a complete stop of communication with this node. This can lead to many different problems.

How to repeat:
Very difficult to reproduce, but usually leads to GCP stop or something similar.

Suggested fix:
Fix list management in setNeighbourNode in mt.cpp.

[7 May 2022 16:40] MySQL Verification Team

Hello Mikael,

Thank you for the report and feedback.

Sincerely,
Umesh

[26 Oct 2023 9:25] Ole John Aske

Posted by developer:
 
Implementation of setNeighbourNode in 8.0.29 has been reviewed.

Bug report describe:
.............................
In setNeighbourNode we remove transporters from the list of transporters that 
are ready to send. The removed transporters are moving to become neighbour 
transporters.
 
However the removal function is supposed to remove it from a single linked 
list with first and last pointers. The update of the last pointer is missing 
and the previous pointer is supposed to be updated in the loop, but it is 
only initialised and not updated in the loop.
.............................

There is no 'removal' of transporters from 'list of transporters' taking
place in setNeighbourNode() - It simply sets the transporter
to be handled as a 'neighbour' and assign a send_thread to handle
the transporter.

Could the described list handling problem possibly be related to
a fork of mysql?