Heob is an OSS project, short for ‘heap observer’.
How to configure and use?
0. The official documentation from Qt/QtCreator is – like always :’D – a bit sparse: https://doc.qt.io/qtcreator/creator-heob.html
1. Get it from: https://github.com/ssbssa/heob/releases (I’ll use here release 3.1 from July 2019) and extract to the directory of your choice. This directory has to be set later as configuration path.
If you use gcc/mingw, then make sure you’ve dwarf-stack enabled. Since I’m just using the MSVC, not much had to be done.
2. Inside QtCreator (I am using right now 4.12 from the Maintenance Installer) go to “Analyze > Heob” and configure it like this:
The floppydisk-icon can be saved to store ONE configuration.
I leave most of the time the tracing to simple, else time-critical processes can fail. The output-files should be named if you do several runs, which you want to compare or post-process. Most of the time it makes sense to start disabled, because else heob tracks already all the losses at start and this will delay the start.
3. As example, I’ve set Cullendula as UUT (unit under test).
Since heob was started disabled, the leak recording is off: Activate it by pressing ‘n’. If you resize the terminal, the last line can become invisible due to some glitch. So better leave the size of the window untouched!
4. Do your favorite workflow in the UUT. Then close/quit the UUT.
5. Depending on how much allocations were done, heob takes more (up to ten minutes!) or less time (seconds in the case of Cullendula) to evaluate the leaks.
The results are sorted in descending order. Expand the entries to check the stack-trace of the cause.
Some can be triggered by leaks in the underlying libraries (Qt .. I am lookin at you: https://bugreports.qt.io/browse/QTBUG-59621), some by your own buggy implementation.
Hint: the generated xml-report can be later loaded again in the results-tab. Or specify “-o leaks20200617.html” for an optically more pleasing result.
having some Qt-SDK without help files. Using help inside a browser is possible, but cumbersome. and local help would be nice for quick parameter-checks.
Found also the official docu at: http://download.qt-project.org/online/qtsdkrepository/windows_x86/desktop/qt5_5121_src_doc_examples/qt.qt5.5121.doc/ as 7z-archive.
Then add it via QtCreator > Tools > Options > Help > Documentation > “add the QCH files”.
The plan is to use the spellchecker from https://github.com/CJCombrink/SpellChecker-Plugin
Let’s be honest: it is quite hard to extract the needed information for a proper setup of the spellchecker. I took me on first try several guesses, which files to download, where to put them and how to configure the dictionary.
Since the process is a bit tricky, my two cents:
- download the current version for Win10 x64 from this page: https://github.com/CJCombrink/SpellChecker-Plugin/releases (currently “SpellChecker-Plugin_v2.0.5_x64.zip”)
- copy&paste the two folders “bin” and “lib” into the current QtCreator 4.11-directory (it has to be that version 4.11 else the plugin fails to load!): for me this is “C:\Qt\Tools\QtCreator”)
- download the proper .aff and .dic files for the dictionary from: https://cgit.freedesktop.org/libreoffice/dictionaries/tree/en – for me “en_US”
- start QtCreator and you should have under “tools > options” a new entry for “SpellChecker” … configure there the dictionary-usage
- restart QtCreator (again!)
- done 🙂
Several instances of vstest.executionengine.clr20.exe are still running, despite closing that nice Visual Studio 2015 and therefore the access to compile and link several DLLs with QtCreator is blocked.
Closing them one by one with the taskmanager is annoying.
* CMD as admin
* $ taskkill /IM vstest.executionengine.clr20.exe /T /F
* or: $ wmic process where name=’vstest.executionengine.clr20.exe’ delete
This error is too ‘good’ to be just put into “Today I learned”.
While adapting some unit-testing-code for one of the classes, I received from minGW a error stating:
C:/Repos/repoName/filename.h:23: Error: Not a signal or slot declaration
What is the problem? The member-declaration looked totally valid.
Until I realized I had removed the (now commented) “private”-statement and therefore the pointers were seen by the MOC as signals/slots. Which they weren’t!
void initTestCase( void );
void cleanupTestCase( void );
classA* _serialPort = nullptr;
classB* _flickerSensor = nullptr;
Shame on me :’)
Currently the debugging version of the Qt-libraries is not available. But I receive a report
"QIODevice::write (QIODevice): Called with maxSize < 0" deep within them.
Our codebase is quite large, I am more familiar with other sections and let's say it: some is 'legacy'. So, where to start looking?!?
Yesterday I remembered a trick to get via call-stack to the last-recent position where our functions trigger that mistake.
Inserted in the main.cpp after show from the MainWindow was called a
which stands for this
void messageHandler(QtMsgType type, const QMessageLogContext &context, const QString &msg )
switch( type )
case QtDebugMsg: qDebug() << msg.toLatin1().data(); break;
case QtWarningMsg: qDebug() << msg.toLatin1().data(); break;
case QtInfoMsg: qDebug() << msg.toLatin1().data(); break;
case QtCriticalMsg: qDebug() << msg.toLatin1().data(); break;
case QtFatalMsg: qDebug() << msg.toLatin1().data(); break;
default: qDebug() << msg.toLatin1().data(); break;
Add a breakpoint in the messageHandler and debug the app. Maybe disable the breakpoint until you start to trigger the critical functionality.
When it breaks, you have a nice callstack and can backtrace where it came from :)
It’s quite funny if you want to use the current version of your favorite static code analysis-tool, then realize that no OS-binary is availabe, then think “why not create it yourself like you did it with older versions?” (qmake && make ..), then realize your current clang-version does not support the missing c++11-features (cbegin/cend), then you realize you are not allowed upgrade your local compiler ..
To put it in a nutshell:
homebrew install cppcheck && cd <source to check> && cppcheck --enable=all --inconclusive --std=posix . 2> cppcheck.txt
Yes, this leaves you without the gui, but still better than nothing.
side note: I also found the cppcheck-plugin for QtCreator-project on sourceforge (new since august 2015?), but since the contributor provides just Win and Linux binaries, but neither source nor OSX-binaries, I have to wait. But looks promising.
Only fifteen hours after my request the russian mastermind behind the project built an OSX-dylib for the cppcheck-plugin and offered it to me for testing. After update from QtCreator 3.42 to 3.5, copying the plugin, activating it and setting the path to the homebrew-1.70-cppcheck, everything works! No more switching between the cppcheck-output and QtCreator, just fix the issues! *feels good*
Now it is officially available. Enjoy!