1. machine_info.h: zero-initialise Screen struct members
Max_width, Max_height, count, width[] and height[] were bare
int32_t with no initialiser. The comparisons in
init_get_Screen_info() read them before any write, producing
undefined behaviour flagged by Valgrind as 'Conditional jump
or move depends on uninitialised value(s)'.
2. main.cpp: pre-initialise MachineInfo on the main thread
MachineInfo::instance() was first called inside QtConcurrent::run(),
causing its constructor (which calls qApp->screens()) to run on a
background thread. QScreen methods are not thread-safe in Qt5.
Calling instance() once on the main thread before the worker
launches guarantees the singleton is fully built first; subsequent
calls from the worker just return the cached pointer.
3. qetdiagrameditor.h: move m_first_show before the QActionGroup members
C++ initialises members in declaration order. m_first_show was
declared after the QActionGroup members (line 256 vs 168). During
construction of m_row_column_actions_group(this), Qt dispatches a
QObject parent-change event that reaches QETDiagramEditor::event(),
which reads m_first_show before it has been initialised.
Moving the declaration to the top of the first private: block
ensures it is initialised before any member that can trigger events.
All three found via Valgrind --tool=memcheck on Ubuntu 22.04 / Qt 5.15.3.
Relates-to: PR #514 (same QtConcurrent thread-safety pattern).
Shane Ringrose
c586a2d3a3