Re: [Interest] Segmentation fault on exiting Qt event loop

[Roland Hughes]

On 1/9/19 4:00 AM, Reinhardt Behm wrote:

On Wednesday 09 January 2019 08:57:23 alexander golks wrote:

Am Tue, 8 Jan 2019 06:15:08 -0600

schrieb Roland Hughes:

only NASA pre-faster-cheaper-splat days had more rigorous development
rules and physical testing

yes, indeed;)
https://en.wikipedia.org/wiki/List_of_software_bugs

Interesting read about the space shuttle people:



Great link!  Thanks! Wish I had time to read it all right now. Love this 
bit though.




That’s the culture: the on-board shuttle group produces grown-up 
software, and the way they do it is by being grown-ups. It may not be 
sexy, it may not be a coding ego-trip — but it is the future of software.




The lead up to it is beautiful. AGILE is a Romper Room activity. Keeps 
the kids entertained until they get tired while parents hope they grow 
up and leave the house any day now.


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Reinhardt Behm via Interest]

On Wednesday 09 January 2019 08:57:23 alexander golks wrote:
> Am Tue, 8 Jan 2019 06:15:08 -0600
> 
> schrieb Roland Hughes :
> > only NASA pre-faster-cheaper-splat days had more rigorous development
> > rules and physical testing
> 
> yes, indeed ;)
> https://en.wikipedia.org/wiki/List_of_software_bugs

Interesting read about the space shuttle people:


-- 
Best Regards

Reinhardt Behm



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[alexander golks]

Am Tue, 8 Jan 2019 06:15:08 -0600
schrieb Roland Hughes :

> only NASA pre-faster-cheaper-splat days had more rigorous development 
> rules and physical testing

yes, indeed ;)
https://en.wikipedia.org/wiki/List_of_software_bugs

-- 
/*
 *There is no character, howsoever good and fine, but it can be destroyed by
 *ridicule, howsoever poor and witless.  Observe the ass, for instance: his
 *character is about perfect, he is the choicest spirit among all the humbler
 *animals, yet see what ridicule has brought him to.  Instead of feeling
 *complimented when we are called an ass, we are left in doubt.
 *-- Mark Twain, "Pudd'nhead Wilson's Calendar"
 */


pgpQxOu3c6b8U.pgp
Description: Digitale Signatur von OpenPGP
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Roland Hughes]

On 1/8/2019 4:00 AM, Thiago Macieira wrote:

On Sunday, 6 January 2019 14:16:38 PST Roland Hughes wrote:

And those devices still have an input mechanism: their scanner ports. It's
possible to send malformed data to their I/O pins to cause an exploit.
Heck, it's theoretically possible to do that with the scanning head
itself: paint your chest with some pattern in UV and when you go for a
tomography, bam! the device gets hacked. Remember how the iPhone 1 was
jailbroken by a 1x1 pixel TIFF image opened in the Safari browser?

I have no idea what you are speaking of here. Perhaps it is from a part
of the medical device world I've never worked in. None of the devices
I've worked with have exposed I/O pins.

They don't need to be exposed directly for data to be sent to them. The
medical devices have probes, image and video acquisition, etc. You can hack
through those. Granted, this would be a terribly difficult hack and the hacker
would be right there visible to everyone, but it's theoretically possible.


Maybe that will work on one designed and built in North Korea then 
smuggled into the country, but, not on anyone I've worked on or heard 
about designed and built in America. That stuff is all modular. It will 
look like a single device, but, that is the visual magic of the case. 
Any byte outside of a limited range value in the fixed size message and 
to the bit bucket it goes.


Now if you are talking about _consumer_ products which measure blood 
pressure, heart rate, glucose "for entertainment purposes" ala FitBit 
and some devices potentially sold at drugstores but __definitely__ sold 
on Amazon.com which __never__ went through FDA regulated development 
process and cannot legally call themselves "medical devices" in any way 
shape or form, yes, all kinds of badness is most likely there. But for 
stuff legally allowed to call itself a medical device in this country, 
only NASA pre-faster-cheaper-splat days had more rigorous development 
rules and physical testing. This is why all of those late night lawyer 
commercials you see are for drugs and implants.


Diagnostic and monitoring equipment has required periodic manual checks. 
Even if you are hooked up to a 24x7 full vitals monitor medical staff 
are required to come into the room every so often to manually take your 
vitals. Given level of design document vetting required before the first 
drop of solder can fall and the immensely long clinical trials I'm 
shocked any surgical robot ever makes it to market.


Having said all of that, your fears may become a reality thanks to 
little snot nosed Donny.


https://www.reuters.com/article/us-fda-devices-proposal/fda-proposes-new-fast-path-to-market-for-certain-medical-devices-idUSKBN1E6031

The 510(k) process is how replacement diagnostic equipment with manual 
verification procedures was able to quickly put out lead free 
replacement devices once lobbyists went down in flames trying to 
overthrow the international lead free regulation. My gut tells me this 
new proposal will see a rash of surgical robots attempting to fast track 
and other fools trying to connect their devices to the Internet so they 
can force out mandatory updates either during unsafe times or OS "fixes" 
which haven't really been tested. Not cool. Field updates are currently 
done by trained service personnel to ensure the device isn't in use or 
about to be connected to a patient.




Perhaps I've just been lucky, but every device I've worked on to date
has had isolated components which communicate via a message queue. The
message queue only supports a limited number of serialized messages
(usually serialized COOA messages with fixed length fields.) If a stream
of garbage came in from a replaceable component, the stream would be
ignored by the message queue and an alarm sounded. Even the USB ports
I've seen on them will not communicate with an off-the-shelf keyboard,
mouse, thumb drive, or insert USB device here. Only a limited set of
custom devices could connect in any way.

But there's a higher layer that parses the messages that were received. My
point is that a suitably crafted message could trigger an exploit / DoS in the
device. And again, you don't need access to the bytes to send that message,
you can do it by causing the actual capture device generate them.
In theory, if any component were allowed to communicate via dynamic 
streams or used XML your statement would be correct. Each message of a 
certain supported type is a mandatory length with fixed length fields 
all having allowable octate values. Too short, too long, unknown type or 
one octate outside of the allowed range and it goes to the bit bucket.



Maybe the IoT surgical robot is not a 2019 technology, but there are
plenty of other IoT ones that are. Those MUST update. Frequently. For
those, if you're not able to deploy a fix within one week, do us all a
favour and don't sell your device.

Should I assume that last statement was directed at Google and Android?

Re: [Interest] Segmentation fault on exiting Qt event loop

[Roland Hughes]

On 1/4/2019 4:00 AM, Thiago Macieira wrote:

On Thursday, 3 January 2019 11:29:14 -02 Roland Hughes wrote:

Or you architect out everything which could be a security issue. There
is no command line or terminal. The few medical devices I know of
removed all support for inbound connections. The only method of
accessing them is to take the screws out of the case, open it up and
connect the custom debug board.

Physical access is still an attack vector.

And those devices still have an input mechanism: their scanner ports. It's
possible to send malformed data to their I/O pins to cause an exploit. Heck,
it's theoretically possible to do that with the scanning head itself: paint
your chest with some pattern in UV and when you go for a tomography, bam! the
device gets hacked. Remember how the iPhone 1 was jailbroken by a 1x1 pixel
TIFF image opened in the Safari browser?


I have no idea what you are speaking of here. Perhaps it is from a part 
of the medical device world I've never worked in. None of the devices 
I've worked with have exposed I/O pins. Even the patient monitor I 
worked on had to have electrical protection so if someone stabbed the 
thermometer into a wall outlet the current would never get to a patient 
hooked to one of the other leads.


Perhaps I've just been lucky, but every device I've worked on to date 
has had isolated components which communicate via a message queue. The 
message queue only supports a limited number of serialized messages 
(usually serialized COOA messages with fixed length fields.) If a stream 
of garbage came in from a replaceable component, the stream would be 
ignored by the message queue and an alarm sounded. Even the USB ports 
I've seen on them will not communicate with an off-the-shelf keyboard, 
mouse, thumb drive, or insert USB device here. Only a limited set of 
custom devices could connect in any way.


While any component could theoretically fail, it cannot damage the unit 
itself. Physical access can damage the unit itself assuming one wishes 
to hit it with a hammer or throw it down several flights of concrete 
stairs but the OS on many/most devices is not alterable in the field 
without a soldering iron to replace the read only medium the OS is 
stored on. Writable media is only used for the storing of data, logs and 
configuration settings. Invalid/illegal settings are ignored and 
generally when encountered at the start of some run cause the machine to 
return to safe mode with some kind of "wrench" screen being displayed. 
As a general rule you cannot select a different protocol without 
stopping one run and starting a new one. Whether you believe me or not, 
the independent testing agencies try feeding every illegal character and 
configuration value set through each device they test.




But I do understand the cost of re-certifying a medical or avionic device. I'm
not saying people should update every day or every week, but they should still
keep up with the software, in their development tree. So like Konstantin said,
they will not be surprised when the time to update does come.
This is a bit of a misconception. A company isn't allowed to "update" 
it's tool set without going through the full development process of 
creating all of the documentation, getting approval, complete test set, 
etc. The required QA process can be shorter, depending on the scope of 
the change. A fix to correct a memory leak in a core tool like say, some 
Qt class, could theoretically get through in months. Changing out a tool 
like, say, "updating" from Qt 4.8 to 5.9 is treated as a new product. 
Some companies may be able to get that treated as just an "enhancement" 
but, generally it is viewed and treated as a new replacement product for 
an existing product. Even with an accelerated approval process you will 
be looking at a year or more from the time you start and several million 
dollars spent.

Do you really want a surgical robot which is cutting on you running a PC
OS on a PC processor able to connect to the Internet? Some little hacker
poking around looking for financial/identity information could
accidentally have it remove your heart instead of your appendix.

Yes, so long as that device does proper security hardening, which includes the
ability to deploy fixes quickly. It also means it's not your regular desktop
OS, but a hardened version, like Safety Critical Linux. We had this discussion
20 years ago, when Linux was getting into telcos, and Carrier-Grade Linux came
about.

Maybe the IoT surgical robot is not a 2019 technology, but there are plenty of
other IoT ones that are. Those MUST update. Frequently. For those, if you're
not able to deploy a fix within one week, do us all a favour and don't sell
your device.


Should I assume that last statement was directed at Google and Android? 



https://en.wikipedia.org/wiki/Android_version_history

Re: [Interest] Segmentation fault on exiting Qt event loop

[Thiago Macieira]

On Thursday, 3 January 2019 11:29:14 -02 Roland Hughes wrote:
> Or you architect out everything which could be a security issue. There
> is no command line or terminal. The few medical devices I know of
> removed all support for inbound connections. The only method of
> accessing them is to take the screws out of the case, open it up and
> connect the custom debug board.

Physical access is still an attack vector.

And those devices still have an input mechanism: their scanner ports. It's 
possible to send malformed data to their I/O pins to cause an exploit. Heck, 
it's theoretically possible to do that with the scanning head itself: paint 
your chest with some pattern in UV and when you go for a tomography, bam! the 
device gets hacked. Remember how the iPhone 1 was jailbroken by a 1x1 pixel 
TIFF image opened in the Safari browser?

But I do understand the cost of re-certifying a medical or avionic device. I'm 
not saying people should update every day or every week, but they should still 
keep up with the software, in their development tree. So like Konstantin said, 
they will not be surprised when the time to update does come.

And please don't forget all other segments, where updating *is* possible and 
even necessary, if they are connected to *any* kind of network.

> Do you really want a surgical robot which is cutting on you running a PC
> OS on a PC processor able to connect to the Internet? Some little hacker
> poking around looking for financial/identity information could
> accidentally have it remove your heart instead of your appendix.

Yes, so long as that device does proper security hardening, which includes the 
ability to deploy fixes quickly. It also means it's not your regular desktop 
OS, but a hardened version, like Safety Critical Linux. We had this discussion 
20 years ago, when Linux was getting into telcos, and Carrier-Grade Linux came 
about.

Maybe the IoT surgical robot is not a 2019 technology, but there are plenty of 
other IoT ones that are. Those MUST update. Frequently. For those, if you're 
not able to deploy a fix within one week, do us all a favour and don't sell 
your device.

> Control systems have to be sealed.

To an extent. I agree that there needs to be sufficient separation. But it 
will be short of a full airgap.

See also the Industry 4.0 activities in Europe and China. The OT networks 
where control commands are currently transiting is merging with the IT 
network. There will still be some separation, bandwidth reservation, priority 
queues, etc., but the wire will likely be the same.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Roland Hughes]

On 1/3/2019 4:00 AM, Thiago Macieira wrote:

On 1/2/2019 4:00 AM, Thiago Macieira wrote:

I understand you're working with 4.8. I don't care.

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.

And in those 10-20 years, they're going to get 20-40 updates of Qt.
No, they're not. They will get what they got with 4.8 and that's it. 
Some of their developers will periodically monitor "fixes" to later 
releases to see if such things can or should be applied to their source 
base. Many will just work around issues. Some shops reportedly fixed 
things in 4.8 they found, but the fix submission process was so onerous 
those fixes exist only in one shop.



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.

Then they should acquire professional support for their devices, if they need
to keep running on old, not-otherwise-supported versions. The community has
limited resources and I'm not being paid a dime to support old versions, nor
is the company I work for.
They end up supporting it themselves and banding with other 
non-competing companies to maintain a common distro.


If you're choosing to stick to an old version, you MUST have a support
mechanism for all your software (not just Qt) because of security issues. For
example, Qt 4.8 is contemporaneous with OpenSSL 1.0.0 and Linux 3.1, both of
which are full of known security issues. So you must either have the knowledge
in-house or you must have an external contract to update those with fixes. It
would be irresponsible to do otherwise. So why not the same for Qt?


Or you architect out everything which could be a security issue. There 
is no command line or terminal. The few medical devices I know of 
removed all support for inbound connections. The only method of 
accessing them is to take the screws out of the case, open it up and 
connect the custom debug board. Those few which do "connect" with 
external systems are required to initiate the connection themselves with 
a limited pre-configured on the device set of hosts. They push data up 
in a proprietary manner and, if needed, pull data in a proprietary 
manner, all from within a connection they initiate.


Do you really want a surgical robot which is cutting on you running a PC 
OS on a PC processor able to connect to the Internet? Some little hacker 
poking around looking for financial/identity information could 
accidentally have it remove your heart instead of your appendix.


I only know of one medical system that touches the patient where some 
Phd. fool touting their John's Hopkins creds planned on using "either 
Windows or Ubuntu desktop" to run it. They spent in excess of a year 
(might still be) talking to senior tech people looking for an 
"architect" to "design" the system, yet wouldn't let them take it off 
the desktop. Yeah, I was one they talked with and I hung up on them. It 
was a clot monitor for post-op patients too. If they __ever__ manage to 
push that through FDA (and I cannot see how it would ever make it 
running on _any_ desktop) they will be in those late night 800 number 
lawyer commercials for exactly the same reasons you are talking about. 
An out of the box desktop has gaping security issues well known on the 
Dark Web. Adding insult to injury, anything else could be installed on 
there. A user will have to be logged in with the application running 
which means anyone who is bored could rotate around to watch cat videos 
on You-tube.


Control systems have to be sealed.

Now, if you want a catcher app which runs on any desktop and listens to 
packets broadcast by a control system, that is completely different. 
They wanted the control system on the desktop.


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

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Roland Hughes]

On 1/3/2019 12:22 AM, Konstantin Shegunov wrote:
On Wed, Jan 2, 2019 at 5:55 PM Roland Hughes 
mailto:rol...@logikalsolutions.com>> wrote:


By then, Qt has abandon them.

Yeah, recently I had worked on a couple of projects for one such 
company (in aviation meteorology). They were "abandoned" for many 
years because it takes at least minimal effort to actually follow the 
new releases and support your code, which they did not.


Yeah "minimal effort." If they were actually able to move in the time 
you mention, then their stuff must not have played in the heavily 
regulated side of the FAA. Someone, I forget who, has already piped up 
that something as "simple" as changing to a new compiler version is a 
4-6 week effort FOR THE COMPANY. Developers, documentation group and the 
QA department. For a medical device, even one which poses "minimal" 
direct risk to the patient like those patient monitors they hook people 
up to in ER, this involves:


A documentation team completing all of the required FDA device change 
documentation including a complete test plan.


Review of said documentation by the FDA followed up by meetings with FDA 
to get approval for said change.


Then and only then, are you allowed to start coding.

This is followed by intensive internal QA per the test plan. In parallel 
you are establishing the manufacturing line with all required controls 
and documentation including training of the workers who will build the 
final product. This final product is the one you and the external teams 
are required to be testing on. It has to come off the actual production 
line.


At least one, sometimes multiple external QA by one or more companies 
selected/approved by the FDA.


Once you pass all of that you go to field/clinical trials for months and 
in many cases years.


I could have left out a few steps. Usually not brought in until the 
coding stage.


I was on one of these projects which resulted from the lead-free 
requirement.


https://www.eetimes.com/document.asp?doc_id=1169679

From start of coding until external QA it was 8+ months involving teams 
plural at multiple locations.


The project happened because one chip supplier refused to versions of 
the same chips which could be soldered with something other than lead 
based solder. As soon as one thing has to change the entire process starts.



 Complex programs won't just run by themselves forever if you are not 
willing to put in the time to support them, don't expect others to do 
the dirty work for you. Just hoping, and also spreading such 
expectations, that a library (or a system) is going to guarantee 
compatibility and at the same time get updates forever is neither 
realistic, nor is it going to happen, Qt is no exception.


You know. I only hear that from the PC world. In the world of real 
systems it is the norm. The Irish Rail system ran north of 17 years on 
an OpenVMS cluster 24x7 without a moment of outage despite upgrades. 
It's not unique. When the OS moved from the 32-bit VAX platform to the 
64-bit Alpha platform there was even a VEST (VAX Environment Software 
Translator) utility provided for customers who only had a binary because 
they purchased software from a company which wasn't around anymore. 
Something similar existed for the move from Alpha to Itanium but I was 
never at a place where anyone used it.


IBM had a rather similar non-event move for customers moving from MVS to 
Z/OS. At least the few customers I have contact with who made the move 
said it was mostly a non-event. Some of them are running systems 
originally written in the 1970s.


This happens regularly in the business world. It's the expectation of 
the business world and is 100% realistic.


How much really ever has to change with a loan amortization program? It 
requires a base loan amount, origination date, number of months, 
interest rate, payment frequency and a compounding factor. From that it 
generates the payment report. These programs weren't even impacted 
during Y2K because they had to solve Y2K when they were originally 
written in the 1970s. Those 30 year mortgages didn't end until after 2000.


Additional obnoxious and irrelevant stuff I have no intent addressing at 
all.


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

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Konstantin Shegunov]

On Wed, Jan 2, 2019 at 5:55 PM Roland Hughes 
wrote:

> By then, Qt has abandon them.


Yeah, recently I had worked on a couple of projects for one such company
(in aviation meteorology). They were "abandoned" for many years because it
takes at least minimal effort to actually follow the new releases and
support your code, which they did not. And as Qt6 is peeking around the
corner, they've finally ported the old code to Qt5 (5.6). I wonder how much
time it's going to take them to get from Qt5 to Qt6, perhaps I'll be old
and frail by then. Complex programs won't just run by themselves forever if
you are not willing to put in the time to support them, don't expect others
to do the dirty work for you. Just hoping, and also spreading such
expectations, that a library (or a system) is going to guarantee
compatibility and at the same time get updates forever is neither
realistic, nor is it going to happen, Qt is no exception.

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.


Removal from the children list is done through an event, not through
connecting to QObject::destroyed. The latter is for your convenience.

2) Forget all assumptions about what one can do in threads and how to
> create them.
> ...
> When it comes to threading, don't derive from QThread.


Deriving from QThread (or using QThread::create) is perfectly valid if you
don't intend to process events. Also everything that's done with an event
loop can be done without, it just takes more effort and care.


> [...]
>

Additional obnoxious and irrelevant stuff I have no intent addressing at
all.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Konstantin Shegunov]

On Wed, Dec 19, 2018 at 11:51 AM 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()?
>

Your example code clearly shows otherwise. You have a QObject that's
created before and destroyed after the application object.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Thiago Macieira]

On Wednesday, 2 January 2019 13:42:29 -02 Jason H wrote:
> I often find that when generating a minimal example, I find the true nature
> of the bug.

My evil plan unveiled!

That's exactly the reason I was explicit on the 200 lines. That's usually such 
a high bar that people end up finding their problem.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Uwe Rathmann]

On Thu, 20 Dec 2018 20:27:30 -0200, Thiago Macieira wrote:

> I understand you're working with 4.8. I don't care.

I participated in one of the marketing road shows of the Qt company in 
Munich/2017: one of the speakers asked the audience which Qt version they 
are using.

I don't have exact numbers, but to me it looked like about 25-33% of the 
fingers were for Qt4.

Uwe



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Thiago Macieira]

On Wednesday, 2 January 2019 12:29:24 -02 Roland Hughes wrote:
> On 1/2/2019 4:00 AM, Thiago Macieira wrote:
> > I understand you're working with 4.8. I don't care.
> 
> 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.

And in those 10-20 years, they're going to get 20-40 updates of Qt.

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

Then they should acquire professional support for their devices, if they need 
to keep running on old, not-otherwise-supported versions. The community has 
limited resources and I'm not being paid a dime to support old versions, nor 
is the company I work for.

If you're choosing to stick to an old version, you MUST have a support 
mechanism for all your software (not just Qt) because of security issues. For 
example, Qt 4.8 is contemporaneous with OpenSSL 1.0.0 and Linux 3.1, both of 
which are full of known security issues. So you must either have the knowledge 
in-house or you must have an external contract to update those with fixes. It 
would be irresponsible to do otherwise. So why not the same for Qt?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Jason H]

> Sent: Wednesday, January 02, 2019 at 7:24 AM
> From: "Thiago Macieira" 
> To: interest@qt-project.org
> Subject: Re: [Interest] Segmentation fault on exiting Qt event loop
>
> On Tuesday, 1 January 2019 14:48:59 -02 Ramakanth Kesireddy wrote:
> > Please find the sample application attached which throws segmentation fault
> > on click of Quit button in the UI.
> 
> I asked for a short example (200 lines or less, single file). You sent a 9-
> file source plus a .ui file.
> 
> I also asked for something that compiles and reproduces the error with a 
> current version of Qt 5. Your code doesn't. Even after fixing it to compile 
> with Qt 5, it produces no error with 5.12, either because you've removed the 
> problem from your test, or because the problem you're running into does not 
> exist in my version.

I often find that when generating a minimal example, I find the true nature of 
the bug. Sometimes, it's my fault, other times it's really a bug. While no one 
wants to actually do the exercise of creating the minimal test case (because it 
should "just work"), It's invaluable because you explicitly state what you did 
to get the behavior your got. Really, a minimal example is not an unreasonable 
ask, it is the minimal ask that can be done with any sufficient specificity. 
Then, if a fix to Qt is actually needed, your example can become one or more 
test cases. It's not reasonable to ask someone else to figure out your problem 
and then come to a solution for it. Also, when supplying the example, you can 
also show when it does work. (Although this technically goes beyond minimal, 
which is fine). This proves that you understand the API and hints to the 
defective mechanism in the code.

In my recent years, having been influenced by having been at various Agile 
departments, I am finding the approach of first principles ( 
https://en.wikipedia.org/wiki/First_principle ) applies well to Agile. I can't 
really express how this affects my work, other than to say to prove it can be 
done in general then done with specificity to your use case. If you target your 
use case directly and first, then you don't know if 1) your premise is correct, 
2) or that you're going about it correctly (including API usage) or 3) your use 
case is correct. Once the problem is solved for the general case, you can solve 
for any specific cas. Knowing that 1 and 2 work really help focus your efforts. 
This also helps identify reusable and conceptual APIs that should be created. 
Solve the equation, *then* plug your values in. Then when developing larger 
systems, you know all the components work, and it's just a matter of tying them 
together. 




___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [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
   , reimplement
   theQThread::run
   () method and
   useQThread::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 

Re: [Interest] Segmentation fault on exiting Qt event loop

[Thiago Macieira]

On Tuesday, 1 January 2019 14:48:59 -02 Ramakanth Kesireddy wrote:
> Please find the sample application attached which throws segmentation fault
> on click of Quit button in the UI.

I asked for a short example (200 lines or less, single file). You sent a 9-
file source plus a .ui file.

I also asked for something that compiles and reproduces the error with a 
current version of Qt 5. Your code doesn't. Even after fixing it to compile 
with Qt 5, it produces no error with 5.12, either because you've removed the 
problem from your test, or because the problem you're running into does not 
exist in my version.

Since you were not capable of following instructions so far, I'm going to 
ignore this problem.

PS: when sending files to other people, do not send generated files (no .o, no 
binaries, no ui_*.h, no moc_*, no Makefiles, no *.pro.user).

PPS: please only say "throw" if your code actually has a "throw" statement.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Nikos Chantziaras]

Your test application runs fine here. However, that's on Qt 5. I don't 
have Qt 4.


The only thing that comes to mind here is that you are creating a 
QObject (UiAppInstance) before you create your QApplication. If your 
UiAppInstance in your real code is more involved than in this test app, 
then this might be a problem. Try moving the creating of the 
QApplication instance to main(), *before* the creation of the 
UiAppInstance object.



On 01/01/2019 18:48, Ramakanth Kesireddy wrote:

Hi,

Please find the sample application attached which throws segmentation 
fault on click of Quit button in the UI.


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?


Please let me know if it is correct to say that widgets(custom widgets 
with parent) are destroyed by qt but any QObject created without parent 
needs to be destroyed manually?


Best Regards,
Ramakanth

On Fri, Dec 21, 2018 at 4:24 AM Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:


On Wednesday, 19 December 2018 16:34:55 -02 Thiago Macieira wrote:
 >  1) Short: 200 lines or less
 >  2) Self-contained: single file, no #includes other than Qt's and
STL's
 >  3) Compileable: unless you meant to show a compilation problem
 >  4) Example: demonstrates your problem.
 >
 > http://sscce.org/

One more thing:
5) is tested with a *supported* Qt version. That's 5.9 or 5.12 today.

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


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Ramakanth Kesireddy]

Hi,

Please find the sample application attached which throws segmentation fault
on click of Quit button in the UI.

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?

Please let me know if it is correct to say that widgets(custom widgets with
parent) are destroyed by qt but any QObject created without parent needs to
be destroyed manually?

Best Regards,
Ramakanth

On Fri, Dec 21, 2018 at 4:24 AM Thiago Macieira 
wrote:

> On Wednesday, 19 December 2018 16:34:55 -02 Thiago Macieira wrote:
> >  1) Short: 200 lines or less
> >  2) Self-contained: single file, no #includes other than Qt's and STL's
> >  3) Compileable: unless you meant to show a compilation problem
> >  4) Example: demonstrates your problem.
> >
> > http://sscce.org/
>
> One more thing:
> 5) is tested with a *supported* Qt version. That's 5.9 or 5.12 today.
>
> 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
>
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
<>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Thiago Macieira]

On Wednesday, 19 December 2018 16:34:55 -02 Thiago Macieira wrote:
>  1) Short: 200 lines or less
>  2) Self-contained: single file, no #includes other than Qt's and STL's
>  3) Compileable: unless you meant to show a compilation problem
>  4) Example: demonstrates your problem.
> 
> http://sscce.org/

One more thing:
5) is tested with a *supported* Qt version. That's 5.9 or 5.12 today.

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



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Thiago Macieira]

On Wednesday, 19 December 2018 01:51:24 PST 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()?

Our guessing here won't help.

Please reduce your problem to something you can describe more concisely. I 
recommend attempting an SSCCE: Short, Self-Contained Compileable Example:

 1) Short: 200 lines or less
 2) Self-contained: single file, no #includes other than Qt's and STL's
 3) Compileable: unless you meant to show a compilation problem
 4) Example: demonstrates your problem.

http://sscce.org/

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Ramakanth Kesireddy]

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 Wed, 19 Dec, 2018, 12:03 Konstantin Shegunov  On Tue, Dec 18, 2018 at 8:25 AM Ramakanth Kesireddy 
> wrote:
>
>> Thanks for your mail..Yes did try with valgrind but couldn't detect
>> memory issue may be due to the way our app is designed using threading.
>> But wondering why it throws segmentation fault if qApp instance is
>> created on stack but not on Heap as I understand that it is mandatory to
>> construct qApp instance on stack by design.
>>
>
> QObject (and QCoreApplication) doesn't impose such a limitation, no, you
> can have them in the heap or stack. I'd be really surprised, though, if you
> don't get the same segfault at the point of the delete call. If you mean
> that you just don't free it up, however, then that's a major code smell.
> From your description I'd hazard a guess that you have a QObject which
> outlives the application (probably a global). This is not allowed, and as
> Thiago already said you must clean up before the Q*Application's
> destructor's run.
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Konstantin Shegunov]

On Tue, Dec 18, 2018 at 8:25 AM Ramakanth Kesireddy 
wrote:

> Thanks for your mail..Yes did try with valgrind but couldn't detect memory
> issue may be due to the way our app is designed using threading.
> But wondering why it throws segmentation fault if qApp instance is created
> on stack but not on Heap as I understand that it is mandatory to construct
> qApp instance on stack by design.
>

QObject (and QCoreApplication) doesn't impose such a limitation, no, you
can have them in the heap or stack. I'd be really surprised, though, if you
don't get the same segfault at the point of the delete call. If you mean
that you just don't free it up, however, then that's a major code smell.
>From your description I'd hazard a guess that you have a QObject which
outlives the application (probably a global). This is not allowed, and as
Thiago already said you must clean up before the Q*Application's
destructor's run.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Nikos Chantziaras]

On 18/12/2018 08:14, Ramakanth Kesireddy wrote:
as I understand that it is mandatory to 
construct qApp instance on stack by design.


No, that's not true. You can create it on the heap. Usually there's no 
need to and most people have it on the stack, but since you can't find 
where the bug is, there's nothing wrong with creating it on the heap 
instead.


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Ramakanth Kesireddy]

Thanks for your mail..Yes did try with valgrind but couldn't detect memory
issue may be due to the way our app is designed using threading.
But wondering why it throws segmentation fault if qApp instance is created
on stack but not on Heap as I understand that it is mandatory to construct
qApp instance on stack by design.

On Mon, 17 Dec, 2018, 23:58 Thiago Macieira  On Monday, 17 December 2018 02:43:36 PST Ramakanth Kesireddy wrote:
> > Why does the QApplication instance throw seg fault when created on stack?
>
> Because there's a bug somewhere. It's likely the problem is in your code.
> I
> recommend trying to valgrind your application and/or reducing it until you
> find what the issue is.
>
> > Should the cleanup of resources be done before
> > qApp->quit() is called using aboutToQuit() signal?
>
> Not necessarily. You can clean up after exec() finished. Just remember
> that
> you must clean up all widgets before the QApplication destructor and
> hopefully
> all QObjects before the QCoreApplication one. Depending on unload-time
> destructors is prone to problems.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Konstantin Shegunov]

On Mon, Dec 17, 2018 at 7:00 PM Ramakanth Kesireddy 
wrote:

> Yes we do have Qt running in worker thread(pthread)..Does it throws
> segmentation fault if we donot wait for the thread(like pthread::join) to
> exit event loop and destroy objects accordingly?
>

Segmentation faults are not thrown, they are not exceptions, albeit linux
allows you to catch the system signal. It means you've violated the memory
segment boundary, hence the name, on windows it's called "Access
violation". In any case it's one of the most generic messages for one of
the most common programming bugs - corrupt memory access. To answer your
question, it may, it may not, depends on many things one of which is
execution order, which isn't exactly deterministic when working with
multiple threads without ordering. It's a (serious) bug, so you should fix
it.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Thiago Macieira]

On Monday, 17 December 2018 02:43:36 PST Ramakanth Kesireddy wrote:
> Why does the QApplication instance throw seg fault when created on stack?

Because there's a bug somewhere. It's likely the problem is in your code. I 
recommend trying to valgrind your application and/or reducing it until you 
find what the issue is.

> Should the cleanup of resources be done before
> qApp->quit() is called using aboutToQuit() signal?

Not necessarily. You can clean up after exec() finished. Just remember that 
you must clean up all widgets before the QApplication destructor and hopefully 
all QObjects before the QCoreApplication one. Depending on unload-time 
destructors is prone to problems.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Ramakanth Kesireddy]

Yes we do have Qt running in worker thread(pthread)..Does it throws
segmentation fault if we donot wait for the thread(like pthread::join) to
exit event loop and destroy objects accordingly?

On Mon, 17 Dec, 2018, 17:00 Konstantin Shegunov  On Mon, Dec 17, 2018 at 1:26 PM Andrew Ialacci  wrote:
>
>> I’ve had this issue on Windows especially when destroying worker threads
>> on an application exit.
>>
>
> Which you shouldn't do.
>
> What I ended up doing was sleeping the main thread until each worker
>> threads isRunning() return false;
>>
>> I’d love to know if this is the //best// solution to this problem but
>> from what I’ve found it works very well.
>>
>
> Nope. Call QThread::quit or QThread::requestInterruption (depending on
> whether you have a running event loop in the thread(s)). And wait for them
> with QThread::wait before allowing the QThread objects to be destroyed.
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Konstantin Shegunov]

On Mon, Dec 17, 2018 at 1:39 PM Andrew Ialacci  wrote:

> Assuming each threads quit() is called and all operations are stopped in
> each thread correctly is using a loop and sleep still ok?
>

Ok's a relative term, but I wouldn't do (or recommend) it. That's the whole
reason you have QThread::wait (and pthread_join, std::thread::join and so
on) to begin with. Just wait for the threads the usual and recommended way
instead of polling them for no obvious reason. :)

>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Andrew Ialacci]

Wow, Yes!

I forgot to include actually killing the threads first before checking if they 
are running. Oops…

Assuming each threads quit() is called and all operations are stopped in each 
thread correctly is using a loop and sleep still ok?



From: Konstantin Shegunov 
Date: Monday, December 17, 2018 at 12:30 PM
To: Andrew Ialacci 
Cc: Ramakanth Kesireddy , Qt Interest 

Subject: Re: [Interest] Segmentation fault on exiting Qt event loop

On Mon, Dec 17, 2018 at 1:26 PM Andrew Ialacci 
mailto:and...@dkai.dk>> wrote:
I’ve had this issue on Windows especially when destroying worker threads on an 
application exit.

Which you shouldn't do.

What I ended up doing was sleeping the main thread until each worker threads 
isRunning() return false;
I’d love to know if this is the //best// solution to this problem but from what 
I’ve found it works very well.

Nope. Call QThread::quit or QThread::requestInterruption (depending on whether 
you have a running event loop in the thread(s)). And wait for them with 
QThread::wait before allowing the QThread objects to be destroyed.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Konstantin Shegunov]

On Mon, Dec 17, 2018 at 1:26 PM Andrew Ialacci  wrote:

> I’ve had this issue on Windows especially when destroying worker threads
> on an application exit.
>

Which you shouldn't do.

What I ended up doing was sleeping the main thread until each worker
> threads isRunning() return false;
>
> I’d love to know if this is the //best// solution to this problem but from
> what I’ve found it works very well.
>

Nope. Call QThread::quit or QThread::requestInterruption (depending on
whether you have a running event loop in the thread(s)). And wait for them
with QThread::wait before allowing the QThread objects to be destroyed.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Andrew Ialacci]

I’ve had this issue on Windows especially when destroying worker threads on an 
application exit.

What I ended up doing was sleeping the main thread until each worker threads 
isRunning() return false;

Something like:

http://share.dkai.dk/Screen-Shot-2018-12-17-12-01-50-n9RsDe43KW.png

I’d love to know if this is the //best// solution to this problem but from what 
I’ve found it works very well.


From: Interest  on behalf of Ramakanth 
Kesireddy 
Date: Monday, December 17, 2018 at 11:57 AM
To: Qt Interest 
Subject: [Interest] Segmentation fault on exiting Qt event loop

Hi,

I'm using Qt 4.8 on TI Sitara embedded linux.

Firstly, a segmentation fault occurs in the destructors, which are called after 
the event loop is exited. Trying to find the root cause for this.

However, if we comment out the mainwidget destructor call, the QApplication 
instance created on stack throws a segmentation fault.

But if QApplication is created on heap and qApp->quit() loop and destructor is 
not called, the seg fault does not occur.

Why does the QApplication instance throw seg fault when created on stack? Is 
this related to destructor clean up issue?

Should the cleanup of resources be done before
qApp->quit() is called using aboutToQuit() signal?

Best Regards,
Ramakanth

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest