[Interest] Segmentation fault on exiting Qt event loop

[Roland Hughes]

On 1/2/2019 4:00 AM, Thiago Macieira wrote:
> I understand you're working with 4.8. I don't care.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>    Software Architect - Intel Open Source Technology Center
>
That would by why there are hundreds, possibly thousands of companies 
all supporting their own fork of Qt and even more moving away from Qt.

They choose to use Qt.

Takes them 1-4 years to get a product out the door which has a 10-20 
year market life.

By then, Qt has abandon them. There are __many__ medical devices running 
4.8 out in the real world saving lives today. We've had this discussion 
before. Most likely he is working on a medical device as well since 4.8 
seems to be the most popular in that world.

On Wed, 19 Dec 2018 02:11:25 Ramakanth Kesireddy wrote:

Yes QApplication destructor is invoked last..Does it makes sense to use
deleteLater() in the widget destructors instead of existing delete if it
could be cleaned up as part of qApp-quit()?

On Tue, 01 Jan 2019 09:08:44 Ramakanth Kesireddy

However, in the actual application, if we delete the custom widget and
QApplication instance, then it throws segmentation fault on qApp->quit().

If we destroy any QObject without parent, then there is no seg error on
qApp->quit().

Does this error occurs because of double destroy that we manually destroy
objects and later qt also tried to destroy them?


I get this list in digest form so any attachments get stripped which 
means I cannot see the code. Don't have time to look at it right now 
anyway. Finishing up a couple of things and packing the ride to head out 
for another medical device project on Friday. Never enough time when 
starting a new project.

Here is what I remember from using this exact same version on a medical 
device project a few years ago.

1) Never delete an object derived from QObject. If you feel compelled by 
some forced design issue, use deleteLater(). Parents didn't handle the 
external death of their children very well.

http://doc.qt.io/archives/qt-4.8/qobject.html

----

QObjects organize themselves in object trees. When you create a QObject 
with another object as parent, the object will automatically add itself 
to the parent's children() list. The parent takes ownership of the 
object; i.e., it will automatically delete its children in its destructor.

When an object is deleted, it emits a destroyed() signal. You can catch 
this signal to avoid dangling references to QObjects.

----

I don't know for certain and don't care enough to dig into it again, 
but, I believe someone stated at some point that when a parented QObject 
was created some of the parents didn't connect the destroyed() signal to 
a slot which would remove the child from their list. It's a vague memory 
and might never have been anymore than someone's wishful thinking. I 
don't care. It seemed to fit what we found and we worked around the 
limitation.

2) Forget all assumptions about what one can do in threads and how to 
create them.

Sometime close to 4.8 is when the great sea change happened with QThread 
and thread creation. We were supposed to be moving our code to things 
like shown in the first snippet here:

http://doc.qt.io/archives/qt-4.8/qthread.html

But the "Derive a class from QThread" was still littered around the 
Internet.

http://doc.qt.io/archives/qt-4.8/thread-basics.html

  * Derive a class fromQThread
    <http://doc.qt.io/archives/qt-4.8/qthread.html>, reimplement
    theQThread::run
    <http://doc.qt.io/archives/qt-4.8/qthread.html#run>() method and
    useQThread::start
    <http://doc.qt.io/archives/qt-4.8/qthread.html#start>() to run it.

Most of us stumble(d) pretty hard with the "Derive a class from QThread" 
path to threading. Some stumbled so hard they started to mix and match 
Qt threading with third party platform specific threading. They are 
still doing that today. I turned down a project in Loveland, CO just a 
scant few weeks ago where this is happening today. They are trying to 
"sprinkle" Qt into their existing code base, using all of their existing 
serial comm, networking, threading libraries (some rolled themselves I 
believe) and they wonder why they are having problems.

Designs which view Qt as a "pinch of salt for the soup" will always 
yield catastrophes.

When it comes to threading, don't derive from QThread. If someone 
believes the design has forced them into deriving from QThread, change 
the design.

The other problem you will run into with threads is basically problem 1.

If you have communications going on, especially a streaming type 
communication like serial or some flavors of networking, it's not 
uncommon to have a little worker be thread gathering up the octates into 
a dynamically allocated buffer of some kind. When a "full packet" as 
determined by the protocol has been received it puts that into a queue 
structure of some kind where another thread will get to it when it gets 
to it. When that thread is done with it, the dynamic buffer is supposed 
to be freed.

IF you are doing this in 4.8, make it a block of raw RAM, not a QObject 
based thing you create in one thread and nuke in another. I seem to 
remember std::string working okay, but, don't quote me. DO NOT try to 
cheat, using a QString, QByteArray, etc. in the gather thread then using 
data() or constData() to queue up for the chewing thread.

All I remember for now.

Thanks for asking the question. Been meaning to write that stuff down so 
I don't forget even more. Fairly certain I will be working with 4.8 
again in the future. That's quite possibly __the__ most popular version 
in the world of embedded systems, especially embedded systems in the 
medical field.

Sadly I cannot tell you "go here" and you will find all of the embedded 
systems developers working with 4.8. They don't come here. The community 
abandoned them long ago. Your company has to find another company 
(preferably not a competitor) which is using and maintaining their own 
version of 4.8 (lots of them out there) then establish a "mutual 
support" relationship. No, I'm not going to finger past clients or make 
such introductions. Some/many/most of the NDAs would classify that as a 
breach, at least the ones I have.

I hope this has been some tiny bit of help. Now I have to get onto my work.

-- 
Roland Hughes, President
Logikal Solutions
(630) 205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us