Debugging a Thread in Qt Creator
-
form http://doc.qt.io/qt-5/thread-basics.html#gui-thread-and-worker-thread
As mentioned, each program has one thread when it is started. This thread is called the "main thread" (also known as the "GUI thread" in Qt applications). The Qt GUI must run in this thread.
So the Qt GUI must be spawned by the same thread the OS originates, it cannot be on any other thread regardless of where QApplication is living
@VRonin said in Debugging a Thread in Qt Creator:
So the Qt GUI must be spawned by the same thread the OS originates, it cannot be on any other thread regardless of where QApplication is living
Not true. Any thread can be used as the GUI thread, and although unusual it may not be the main thread, i.e.
main().Read and abide by the Qt Code of Conduct
-
@J.Hilk Thanks for asking :) I build the application in debug mode and I press F5 to start the debug process.
Try disabling "Run in terminal" in Qt creator if you haven't tried that. Recently I
postedencountered a bug on the tracker that corresponds to the behaviour you're describing.Edit: Original thread with the corresponding bug report https://forum.qt.io/topic/74646/qt-creator-fails-to-map-breakpoints-sometimes
-
@VRonin said in Debugging a Thread in Qt Creator:
So the Qt GUI must be spawned by the same thread the OS originates, it cannot be on any other thread regardless of where QApplication is living
Not true. Any thread can be used as the GUI thread, and although unusual it may not be the main thread, i.e.
main().@kshegunov Probably a linguistic mistake on my part but that's how I read that paragraph. I think some platforms (Windows?) force that restriction
"La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
~Napoleon BonaparteOn a crusade to banish setIndexWidget() from the holy land of Qt
-
@kshegunov Probably a linguistic mistake on my part but that's how I read that paragraph. I think some platforms (Windows?) force that restriction
@VRonin said in Debugging a Thread in Qt Creator:
I think some platforms (Windows?) force that restriction
I don't believe so, although don't hold me to it.
Also see this post:
https://forum.qt.io/topic/67285/ui-application-as-thread-cpu-load-almost-100/12I can vouch it works fine on Linux for sure.
-
From Jasmin Blanchette, Mark Summerfield, C++ GUI Programming with Qt 4 Chapter 18, Pragraph "Communicating with the Main Thread"
When a Qt application starts, only one thread is runningthe main thread. This is the only thread that is allowed to create the QApplication or QCoreApplication object and call exec() on it. After the call to exec(), this thread is either waiting for an event or processing an event.
This is what put that concept into my mind. I very well admit it might not be the case, wouldn't be the first time that manual was wrong
-
Try disabling "Run in terminal" in Qt creator if you haven't tried that. Recently I
postedencountered a bug on the tracker that corresponds to the behaviour you're describing.Edit: Original thread with the corresponding bug report https://forum.qt.io/topic/74646/qt-creator-fails-to-map-breakpoints-sometimes
@kshegunov said in Debugging a Thread in Qt Creator:
Try disabling "Run in terminal" in Qt creator if you haven't tried that. Recently I posted a bug on the tracker that corresponds to the behaviour you're describing.
I am gonna try this now and get back to you with the results.
Thanks for the thoughts!
-
Thanks for the discussions on GUIThread vs main thread.
However, does it stops me debugging?
Thanks!
Kumara@VRonin said in Debugging a Thread in Qt Creator:
@kshegunov Probably a linguistic mistake on my part but that's how I read that paragraph. I think some platforms (Windows?) force that restriction
I think that paragraph is poorly-written. On Windows and Linux, you can use a non-main thread as your GUI thread. macOS is the one that has the restriction. See http://stackoverflow.com/questions/22289423/how-to-avoid-qt-app-exec-blocking-main-thread/22290909#22290909
(Side note: LQ Widgets spawns a non-main GUI thread. If you're interested in the details, see
startWidgetEngine()andrun()in https://github.com/JKSH/LQWidgets/blob/master/src/Cpp/lqmain.cpp )@kumararajas said in Debugging a Thread in Qt Creator:
Thanks for the discussions on GUIThread vs main thread.
However, does it stops me debugging?
Good question; I don't know the answer. Please let us know your results.
Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches
-
@VRonin said in Debugging a Thread in Qt Creator:
@kshegunov Probably a linguistic mistake on my part but that's how I read that paragraph. I think some platforms (Windows?) force that restriction
I think that paragraph is poorly-written. On Windows and Linux, you can use a non-main thread as your GUI thread. macOS is the one that has the restriction. See http://stackoverflow.com/questions/22289423/how-to-avoid-qt-app-exec-blocking-main-thread/22290909#22290909
(Side note: LQ Widgets spawns a non-main GUI thread. If you're interested in the details, see
startWidgetEngine()andrun()in https://github.com/JKSH/LQWidgets/blob/master/src/Cpp/lqmain.cpp )@kumararajas said in Debugging a Thread in Qt Creator:
Thanks for the discussions on GUIThread vs main thread.
However, does it stops me debugging?
Good question; I don't know the answer. Please let us know your results.
@JKSH said in Debugging a Thread in Qt Creator:
Side note: LQ Widgets spawns a non-main GUI thread.
You have a race condition on initialization, though ... you should switch
Bridge *toQAtomicPointer<Bridge>, since at lines 32 and 57 you touch the pointer from different threads. By the way, what's the problem with using a semaphore to wait for the GUI thread, I really dislike thatwhile (!bridge)line ... -
Try disabling "Run in terminal" in Qt creator if you haven't tried that. Recently I
postedencountered a bug on the tracker that corresponds to the behaviour you're describing.Edit: Original thread with the corresponding bug report https://forum.qt.io/topic/74646/qt-creator-fails-to-map-breakpoints-sometimes
@kshegunov said in Debugging a Thread in Qt Creator:
Try disabling "Run in terminal" in Qt creator if you haven't tried that. Recently I posted encountered a bug on the tracker that corresponds to the behaviour you're describing.
Hi,
I did give a try with this approach. Still no success on not hitting the breakpoint in thread..
-
And here is one observation on Qt Application being on main thread vs worker thread.
When you run Qt application on a main thread, you don't create the thread by yourself, so you don't need to worry about the thread parameters which has been used by Qt internally.
When we create Qt application on a thread, we are suppose to take care of thread parameters.
Example, thread stack size. If you don't set it by yourself, then the linux default stack size for the thread is 2MB. Which will be used for your Qt thread.
And the challenge here is, we don't know what should be the stack size for Qt. We may overrun during long run, so we should keep that in mind. And the challenge is Qt never tell us on how much should be set.I have observed this just today morning. I have set my stack size to 64k and the application was coming up and getting exited in few seconds with segmentation fault error. When I have increased to 128K, application was up for a while, but it crashed later on. Now, I have 256K, which looks good but I never know when it will crash.
Having the stack size challenge aside, I don't think any problem on Qt being on a worker thread.
-
@kshegunov said in Debugging a Thread in Qt Creator:
Try disabling "Run in terminal" in Qt creator if you haven't tried that. Recently I posted encountered a bug on the tracker that corresponds to the behaviour you're describing.
Hi,
I did give a try with this approach. Still no success on not hitting the breakpoint in thread..
@kumararajas said in Debugging a Thread in Qt Creator:
I did give a try with this approach. Still no success on not hitting the breakpoint in thread..
Well, what about the debugger log? It should shed some light on the issue.
When we create Qt application on a thread, we are suppose to take care of thread parameters.
Not really, no.
Example, thread stack size. If you don't set it by yourself, then the linux default stack size for the thread is 2MB.
Which is perfectly fine, I wouldn't mess with the stack size for no good reason.
Now, I have 256K, which looks good but I never know when it will crash.
Then just leave it to the OS!
-
@kumararajas said in Debugging a Thread in Qt Creator:
I did give a try with this approach. Still no success on not hitting the breakpoint in thread..
Well, what about the debugger log? It should shed some light on the issue.
When we create Qt application on a thread, we are suppose to take care of thread parameters.
Not really, no.
Example, thread stack size. If you don't set it by yourself, then the linux default stack size for the thread is 2MB.
Which is perfectly fine, I wouldn't mess with the stack size for no good reason.
Now, I have 256K, which looks good but I never know when it will crash.
Then just leave it to the OS!
@kshegunov said in Debugging a Thread in Qt Creator:
Well, what about the debugger log? It should shed some light on the issue.
Where can I find the debugger log?
And for other answers, excellent. That convinces me!
Kumara
--Kumar
-
@kshegunov said in Debugging a Thread in Qt Creator:
Well, what about the debugger log? It should shed some light on the issue.
Where can I find the debugger log?
And for other answers, excellent. That convinces me!
Kumara
@kumararajas said in Debugging a Thread in Qt Creator:
Where can I find the debugger log?
Window > Views > Debugger Log
-
@kumararajas said in Debugging a Thread in Qt Creator:
Where can I find the debugger log?
Window > Views > Debugger Log
@kshegunov said in Debugging a Thread in Qt Creator:
Window > Views > Debugger Log
Did you mean debug window?
I don't see any on the debug window.
I use Qt Creator 3.2.2, which does not contain "Views" menu.
