Qt Application – Memory Errors

A simply program was created that containing a single main() function with a QApplication instance, a single shot timer to force the program to quit and a call to the Qt event processing executive.  This simply program also had the same memory issues, so this is some sort of issue with Qt, and probably explains why the External Errors are disabled by default in the Analyzer.

The valgrind utility has an option to disable (suppress) errors from being reported.  The ‑‑gen‑suppressions=all option can be used to generate a list of errors to suppress.  These error suppressions (extracted from the output - between the sets of braces) were put into the ibcp.supp file in the test sub-directory.  The memory test script was modified with the ‑‑suppression=$dir/ibcp.supp option where $dir is set to the test sub-directory in the source directory within the script.

This error suppression file can also be added to the Analyzer in QtCreator by going to Options... in the Tools menu and going to the Analyzer options page.  In the Memory Analysis Options section, the Add... button is used to select the ibcp.supp file.  (Note: this is only for running on Linux.)

The commented static linking commands in the CMake file were removed.  Since the executable is now going to require two Qt library files, there is no longer any reason to link the MinGW libraries required by the executable statically.  All the required dynamic link libraries will be included in future releases of the binary zip file for Windows.  If I read the licensing correctly, this is permitted if the libraries were not built from custom source.

[commit  af6faac469]

Qt Application – Building

Now that the program is using the QApplication class, the QtGui component needed to be added to the find package for Qt4 command in addition to the QtCore component in the CMake file. 

Upon testing these changes, there were no differences, however, the memory test reported a number of lost memory blocks.  It was not obvious where the problem was and was just reported on the line with the QApplication app instance.  After much experimentation, the problem was caused by statically linking libgcc and libstdc++.  Without the static linking, there were no more errors - at least when using Analyzer in QtCreator.

When running the memory test script, many more memory errors were reported, again against the QApplication app instance.  These were actually being reported in Analyzer, but were not listed because they were disabled (External Errors on the funnel looking icon on the Analyzer tool bar).

A commit was made with the changes for the QApplication instance and how the command line arguments are handled.  The static linking part of the CMake build file was temporarily commented (this will be dealt with next).

[commit  01a79dda20]

Qt Application – Event Loop

The Qt event loop is started with a call to the exec() member function of QApplication.  Normally when the users requests the program to exit from the GUI, the exec() function returns.  This occurs when the quit() function is called from one of the GUI elements (for example, the close on the application windows of Exit from the File menu).

Since no GUI elements have been implemented yet including any window, somehow the quit() function needs to be called.  This is accomplished with a single shot timer initiated with the call:

QTimer::singleShot(0, &app, SLOT(quit()));

This timer times out immediately and calls the quit() slot of the QApplication instance, but fortunately this does not occur until the exec() function is called.  Once exec() is called, it immediately returns, exiting the application.

Qt Application – Command Line Arguments

Up to now, the source code has been modified to use Qt support classes, but the program is not yet a Qt application.  A Qt application has a GUI (usually though it is possible to have a command line Qt application).  A GUI application has an event processing loop, which basically means that instead of processing sequentially from start to end, it processes events when they occur such as a keyboard press or a mouse click and calling the appropriate function to carry out the selected action.

A Qt application starts by creating an instance of a QApplication (or a QCoreApplication for a command line application).  Since this project will have a GUI, a QApplication instance will be created, but no GUI will be started if either the version or a test mode options are selected on the command line.

The command line arguments, via the argc and argv arguments of main(), are passed to the QApplication constructor because there are some Qt options that can be specified on the command line.  The arguments() member function of QApplication is used to obtain a QStringList of the remaining options (with the Qt options removed).  The first string in this list is still the name of the program.  The argc and argv arguments to the various functions were changed to QStringList &args, which is set to the arguments.