Debugging a Thread in Qt Creator

kumararajas

Hi,

Here is the scenario -

Main process creates Qt Application in a thread and all the Qt resources are being managed over there. And the main process continues perform other activities.

Here, I would like to debug the Qt app which runs on a thread.

I did try many ways but still unable to succeed.

I did enable "Debug All Children", I did add a command "set follow-fork-mode child".

Still no success.

Whereas, I could debug my application from Eclipse IDE. Question is why not Qt Creator?!

Can anyone please help me out?

Thank you,
Kumara

jsulm

@kumararajas "unable to succeed" - can you explain a bit more? What does not work? It doesn't stop at a break point? Something else?
Also, it is unusual to put UI in another thread. Why not keep UI in the main thread and do other stuff in another thread?

kumararajas

@jsulm

Yes, it does not hit the breakpoint in the thread.

And UI being on thread, In my project UI is not a main application. UI is optional. So, there is a main application which creates the thread for UI, if UI is configured.

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

@kumararajas

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!