Debugging a Thread in Qt Creator

VRonin

Qt UI must run on main thread. see http://doc.qt.io/qt-5/thread-basics.html#gui-thread-and-worker-thread

J.Hilk

I'm sorry, but I'll have to ask ;)
You're sure, that you create a debug, not realease, build and that you start the Qt-Debugger, F5-key not CTRL+R?

kumararajas

@VRonin Can we say GUIThread and the MainThread are same?
I see as GUIThread is the one who creates QApplication and the other threads cannot have an access to it. In my case, I do not have a worker thread which does job for Qt, instead my Qt Thread does create Qt resources and accesses them.

Do you see a problem with it?

kumararajas

@J.Hilk Thanks for asking :) I build the application in debug mode and I press F5 to start the debug process.

VRonin

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

kshegunov

@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

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.

Edit: Original thread with the corresponding bug report https://forum.qt.io/topic/74646/qt-creator-fails-to-map-breakpoints-sometimes

VRonin

@kshegunov Probably a linguistic mistake on my part but that's how I read that paragraph. I think some platforms (Windows?) force that restriction

kshegunov

@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/12

I can vouch it works fine on Linux for sure.

VRonin

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

kumararajas

Thanks for the discussions on GUIThread vs main thread.

However, does it stops me debugging?

Thanks!
Kumara

kumararajas

@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!

JKSH

@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() and run() 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.

kshegunov

@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 * to QAtomicPointer<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 that while (!bridge) line ...

kumararajas

@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

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

@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

@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

kshegunov

@kumararajas said in Debugging a Thread in Qt Creator:

Where can I find the debugger log?

Window > Views > Debugger Log

kumararajas

@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.