QApplication in std::thread

Suthiro

Thanks again for your detailed tests and reports.
Unfortunately, static libraries and LoadLibrary() are outside my expertise; I can't think of a reason why static Qt or LoadLibrary() would produce different behaviour compared to dynamic Qt or compile-time linking.

I don't know either. I just started from scratch and found what is different. It is very strange indeed.

By the way, what license are you using Qt under? I you want to use LGPLv3, use statically-linked Qt, AND keep your software closed-source, you'll need to take extra steps to allow your users to switch the version of Qt. (No extra steps needed if your software is open-source)

It is a private project (hobby-related), so I'm okay with any license that allows me to use Qt for personal purposes :). In case I decide to make it public for some reason (unlikely), it will be definitely open-source. TBH I don't need static linking with Qt, it is matter of habit to keep things tidier. So I'll just switch to dynamic linking.

I use MSVC 2017 (toolset v141) on WIndows 7 x64. Compiled qt5.14.1 from source, but also tried some pre-built binaries.

Hmm... the official pre-built binaries are dynamic only. Just to confirm: Does this mean that dynamic Qt crashes from Lua but doesn't crash from your test app?

I tried to reproduce the behaviour with pre-built binaries to no avail, I believe there are/were more than one reason to crash in the "big" project. I was focused at the "QTimer" message and QPushButton interaction troubles, so it is very likely that I broke something else. But now I can get rid at least of this one and proceed further. The example I provided crashes both using lua and test app given that Qt was linked statically.

Add the -developer-build switch when building Qt.
For some types of debugging, the regular Debug build is detailed enough.
The Developer build exports even more debugging symbols from Qt compared to the regular Debug build -- see https://wiki.qt.io/Building_Qt_5_from_Git
Build QtPlotter and link it to the developer build of Qt.
Build your test app.
Use a Debugger to launch the test app (or your Lua app)
I've found that WinDbg provides more details than GDB
Let your app crash and obtain a detailed stack trace from the debugger
If using WinDbg, press 'k' to get the stack trace after the crash

okay, I'll build with -developer-build and report later.

Thank you very much for your help!

kshegunov

@JKSH said in QApplication in std::thread:

Unfortunately, static libraries and LoadLibrary() are outside my expertise; I can't think of a reason why static Qt or LoadLibrary() would produce different behaviour compared to dynamic Qt or compile-time linking.

@Suthiro said in QApplication in std::thread:

TBH I don't need static linking with Qt, it is matter of habit to keep things tidier.

Nothing tidy about that ...

@Suthiro said in QApplication in std::thread:

The true culprit is static linking with Qt libraries: only if Qt was compiled with -static switch crash will occur.

There's a gazillion global variables in Qt that must be initialized properly for things to work. Have you initialized the plugins? (a.k.a. show us the .pro file of your library)