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.o
Faster Cheaper Splat started in 1992.
https://www.jpl.nasa.gov/jplhistory/the90/
Your list had only 1 NASA "bug" prior to that in 1962.
I don't remember if the 1996 prototype rocket explosion was NASA itself
or a third party supplier like the Challenger booster rocket.
After NASA went AGILE,
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
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 b
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
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: p
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 onl
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 th
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
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
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 releas
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 otherwi
On Wednesday, 2 January 2019 16:20:21 -02 Uwe Rathmann wrote:
> 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
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 p
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 number
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
> 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
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
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 ask
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
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 pa
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.o
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.
P
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
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 no
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, t
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 inst
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, th
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
f
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:
>
>
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
, 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 t
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 l
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 usi
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 stac
35 matches
Mail list logo
