…rashes Gpredict. The issue is with how the rot_ctrl_timeout_cb was assigned to a timeout and was documented in #279. The timeout runs the callback function everytime the delay timer runs out. This normally allows for the rotor/display to be updated regularly, with the update interval defined by the user in the "cycle" box.
The problem originates from a duplicate timer that is created in gtk_rot_ctrl_new. When gtk_rot_ctrl_new sets up the widgets. it links the delay_changed_cb to the "cycle" box. Somewhat unintuitively, this action results in delay_changed_cb being called immediately. Every time delay_changed_cb is run, it will delete any existing timeout and create a new one. Later, gtk_rot_ctrl_new creates an additional timeout and forgets the ID of the timeout made by the initial running of the delay_changed_cb. This forgotten timeout will run rot_ctrl_timeout_cb forever. The reason this issue was only observed while the rotor is engaged was because rot_ctrl_timeout_cb can only access freed resources when ctrl->engaged is true.
The solution is to remove the line that creates a rot_ctrl_timeout_cb from gtk_rot_ctrl_new and rely on the initial running of delay_changed_cb to create the timeout.
TL;DR PR corrects memory leak in the rotor control window that sometimes results in a crash.
csete
commented
6 months ago
…rashes Gpredict. The issue is with how the rot_ctrl_timeout_cb was assigned to a timeout and was documented in #279. The timeout runs the callback function everytime the delay timer runs out. This normally allows for the rotor/display to be updated regularly, with the update interval defined by the user in the "cycle" box.
The problem originates from a duplicate timer that is created in gtk_rot_ctrl_new. When gtk_rot_ctrl_new sets up the widgets. it links the delay_changed_cb to the "cycle" box. Somewhat unintuitively, this action results in delay_changed_cb being called immediately. Every time delay_changed_cb is run, it will delete any existing timeout and create a new one. Later, gtk_rot_ctrl_new creates an additional timeout and forgets the ID of the timeout made by the initial running of the delay_changed_cb. This forgotten timeout will run rot_ctrl_timeout_cb forever. The reason this issue was only observed while the rotor is engaged was because rot_ctrl_timeout_cb can only access freed resources when ctrl->engaged is true.
The solution is to remove the line that creates a rot_ctrl_timeout_cb from gtk_rot_ctrl_new and rely on the initial running of delay_changed_cb to create the timeout.
TL;DR PR corrects memory leak in the rotor control window that sometimes results in a crash.