Re: [Development] Backporting the "stop unloading plugins" change to 5.6

2016-10-13 Thread Thiago Macieira 
Em sexta-feira, 14 de outubro de 2016, às 09:11:48 CEST, Liang Jian escreveu:
> It is a pity that qt develpers have made the dicision of not unloading
> plugins and I have to accept the reality.
> But I think we should at least  introduce a method to disable this
> feature at runtime (such as through a enviroment variable) ?

Use QLibrary for your own plugins.

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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Backporting the "stop unloading plugins" change to 5.6

2016-10-13 Thread Thiago Macieira 
Em quinta-feira, 13 de outubro de 2016, às 20:46:46 CEST, André Pönitz 
escreveu:
> It's not about most that don't, but those that do, or that would like to.
> 
> At a certain level of complexity one doesn't only want to load plugins
> on demand, but also unload them when not needed use anymore, or even
> unload/reload as part of an update.

We can revisit the idea for QPluginLoader, which is a public API.

We are talking in this change about QFactoryLoader, which is a Qt API and 
which is ALWAYS used until program exit.

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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Backporting the "stop unloading plugins" change to 5.6

2016-10-13 Thread Liang Jian 
It is a pity that qt develpers have made the dicision of not unloading
plugins and I have to accept the reality.
But I think we should at least  introduce a method to disable this
feature at runtime (such as through a enviroment variable) ?

On Thu, Oct 13, 2016 at 11:16 PM, Thiago Macieira  wrote:

> Em quinta-feira, 13 de outubro de 2016, às 22:00:35 CEST, Liang Jian
> escreveu:
> > Not unloading plugin is really a bad idea.
> > That will make any memory leak detector report tons of leaks even
> run a
> > simplest qt widgets program. Find and fix 'real' memory leak will be much
> > harder than before.
>
> The decision is already taken: Qt has stopped unloading plugins in Qt 5.7.
>
> The question here is what we should do in 5.6.
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Backporting the "stop unloading plugins" change to 5.6

2016-10-13 Thread André Pönitz 
On Thu, Oct 13, 2016 at 08:16:50PM +0200, Thiago Macieira wrote:
> Em quinta-feira, 13 de outubro de 2016, às 19:47:57 CEST, André Pönitz 
> escreveu:
> > I am not concerned about toy applications that gets started and closed
> > by the minute.
> 
> Right. Most applications don't unload their plugins, except at program exit.

It's not about most that don't, but those that do, or that would like to.

At a certain level of complexity one doesn't only want to load plugins
on demand, but also unload them when not needed use anymore, or even
unload/reload as part of an update.

Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Backporting the "stop unloading plugins" change to 5.6

2016-10-13 Thread Thiago Macieira 
Em quinta-feira, 13 de outubro de 2016, às 19:47:57 CEST, André Pönitz 
escreveu:
> I am not concerned about toy applications that gets started and closed
> by the minute.

Right. Most applications don't unload their plugins, except at program exit.

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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Backporting the "stop unloading plugins" change to 5.6

2016-10-13 Thread Konstantin Tokarev 


13.10.2016, 20:39, "André Pönitz" :
> On Thu, Oct 13, 2016 at 08:01:57PM +0300, Konstantin Tokarev wrote:
>>  > I still consider the approach of not unloading plugins fundamentally
>>  > wrong. It only deepens the trench between Qt and valid approaches at
>>  > software architectures.
>>
>>  I think not unloading plugins is fundamentally right thing to do, if
>>  user does not request unload explicitly.
>
> What should happen *if* the user requests unloading explictly?

I think it should be unloaded completely if platform supports that.

>
> Andre'
>
> PS:
>
>>  * It's not supported on all platforms (e.g., uclibc and musl implement
>>  dlclose() as a stub).
>
> Qt was never about providing common subsets of all supported platforms.
>
>>  * At application exit OS will unload plugins and clean up related
>>  resources much faster than it could be implemented with unload in
>>  destructors.
>
> I am not concerned about toy applications that gets started and closed
> by the minute.

* Do your applications load different plugins every minute? In many cases same
plugins are needed for the whole lifetime of application.

* In case of very large applications shutdown time is important as well,
as it can become annoyingly large.

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Backporting the "stop unloading plugins" change to 5.6

2016-10-13 Thread André Pönitz 
On Thu, Oct 13, 2016 at 08:01:57PM +0300, Konstantin Tokarev wrote:
> > I still consider the approach of not unloading plugins fundamentally
> > wrong. It only deepens the trench between Qt and valid approaches at
> > software architectures.
> 
> I think not unloading plugins is fundamentally right thing to do, if
> user does not request unload explicitly.

What should happen *if* the user requests unloading explictly?

Andre'

PS:

> * It's not supported on all platforms (e.g., uclibc and musl implement
> dlclose() as a stub).

Qt was never about providing common subsets of all supported platforms.

> * At application exit OS will unload plugins and clean up related
> resources much faster than it could be implemented with unload in
> destructors.

I am not concerned about toy applications that gets started and closed
by the minute.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Backporting the "stop unloading plugins" change to 5.6

2016-10-13 Thread Konstantin Tokarev 


13.10.2016, 19:39, "André Pönitz" :
> On Thu, Oct 13, 2016 at 03:30:22PM +0100, Sergio Martins wrote:
>>  On 2016-10-12 20:59, Thiago Macieira wrote:
>>  >Hello
>>  >
>>  >We've got a number of issues that got fixed in 5.7 by the change that made
>>  >QFactoryLoader stop unloading plugins (notably, the Network Manager bearer
>>  >plugin). Given that QtDBus in 5.6 is now heavily threaded, a number of new
>>  >issues have cropped up. I've managed to fix some, but reports from Ubuntu
>>  >developers indicate the latest fix only uncovered the next issue.
>>
>>  Hi,
>>
>>  More importantly, this also solves all the QStringLiteral related crashes
>>  we've been seeing.
>
> These would be fixable by going back to QLatin1String.
>
>>  We need this in 5.6, but it's too big a behaviour change for an LTS release.
>>  We need at least a variable to turn it on/off.
>>
>>  Suggestion which me and peppe discussed:
>>
>>  Make it opt-in in 5.6.3 and write in the ChangeLog that there will be a
>>  behaviour change in 5.6.4.
>>  Make it opt-out in 5.6.4 (bringing it on-par with 5.8).
>>
>>  This gives the user a pre-warning of 3 months, it can still be turned off
>>  and fixes many crashes.
>
> I still consider the approach of not unloading plugins fundamentally
> wrong. It only deepens the trench between Qt and valid approaches
> at software architectures.

I think not unloading plugins is fundamentally right thing to do, if user does 
not
request unload explicitly.

Rationale:

* It's risky when plugin uses any non-trivial piece of software, leaving alone 
any
Qt-specific issues, so it's a responsibility of user to ensure that plugin is 
doing
it's deinitialization correctly on all target platforms, and only allow true 
unloading
if this is the case.

* It's not supported on all platforms (e.g., uclibc and musl implement dlclose()
as a stub).

* At application exit OS will unload plugins and clean up related resources much
faster than it could be implemented with unload in destructors.

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Backporting the "stop unloading plugins" change to 5.6

2016-10-13 Thread André Pönitz 
On Thu, Oct 13, 2016 at 03:30:22PM +0100, Sergio Martins wrote:
> On 2016-10-12 20:59, Thiago Macieira wrote:
> >Hello
> >
> >We've got a number of issues that got fixed in 5.7 by the change that made
> >QFactoryLoader stop unloading plugins (notably, the Network Manager bearer
> >plugin). Given that QtDBus in 5.6 is now heavily threaded, a number of new
> >issues have cropped up. I've managed to fix some, but reports from Ubuntu
> >developers indicate the latest fix only uncovered the next issue.
> 
> Hi,
> 
> 
> More importantly, this also solves all the QStringLiteral related crashes
> we've been seeing.

These would be fixable by going back to QLatin1String.

> We need this in 5.6, but it's too big a behaviour change for an LTS release.
> We need at least a variable to turn it on/off.
> 
> 
> Suggestion which me and peppe discussed:
> 
> Make it opt-in in 5.6.3 and write in the ChangeLog that there will be a
> behaviour change in 5.6.4.
> Make it opt-out in 5.6.4 (bringing it on-par with 5.8).
> 
> This gives the user a pre-warning of 3 months, it can still be turned off
> and fixes many crashes.

I still consider the approach of not unloading plugins fundamentally
wrong. It only deepens the trench between Qt and valid approaches
at software architectures.

Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] macOS CI node segfault

2016-10-13 Thread Alexandru Croitor 
Just got a segmentation fault on OS X 10.9 machine, while compiling, which 
doesn't seem related to moc.

http://testresults.qt.io/logs/qt/qtbase/9859c09bddaf87f49e73c1e8734decab497730ec/OSXOSX_10_08x86_64OSXOSX_10_08x86_64Clangqtci-osx-10.8-x86_64Release_NoFramework/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/testrun_1476370856/testlog.txt.gz

http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1476370856

Regards,
Alex.

On 11 Oct 2016, at 09:23, Jedrzej Nowacki 
> wrote:

Yes, it is possible, but that would be a manual work. From that perspective I 
would prefer to focus on automatic uploading core dumps. Fredrik volunteered to 
look into that (thanks!)

Cheers,
 Jędrek


From: Development 
>
 on behalf of Sérgio Martins >
Sent: Monday, October 10, 2016 4:25 PM
To: Thiago Macieira
Cc: development@qt-project.org
Subject: Re: [Development] macOS CI node segfault

On Sat, Oct 8, 2016 at 9:52 PM, Thiago Macieira
> wrote:
That said, we've known moc has been crashing on Mac for a couple of months and
we have no idea what's causing it.

I recently hit a moc crash when compiling KHTML, then replaced moc
with a script that called "valgrind moc $@", gave the report to
olivier and he fixed it immediately.
Is it possible to trigger a manual build on macOS node and try until
it crashes ?


Regards,
Sérgio Martins
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Backporting the "stop unloading plugins" change to 5.6

2016-10-13 Thread Thiago Macieira 
Em quinta-feira, 13 de outubro de 2016, às 22:00:35 CEST, Liang Jian escreveu:
> Not unloading plugin is really a bad idea.
> That will make any memory leak detector report tons of leaks even run a
> simplest qt widgets program. Find and fix 'real' memory leak will be much
> harder than before.

The decision is already taken: Qt has stopped unloading plugins in Qt 5.7.

The question here is what we should do in 5.6.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Backporting the "stop unloading plugins" change to 5.6

2016-10-13 Thread Giuseppe D'Angelo 

On 12/10/16 20:59, Thiago Macieira wrote:

We've got a number of issues that got fixed in 5.7 by the change that made
QFactoryLoader stop unloading plugins


It's actually 5.8, isn't it? 494376f980e96339b6f1eff7c41336ca4d853065 is 
in 5.8 (and has a documentation bug as it states 5.7!).


Which opens the question of what to do in 5.7, and IMHO the same that 
should happen in 5.6 (see Sérgio's mail) -- 5.7.2 opt-in, 5.7.3 (if it 
ever happens) opt-out.


Cheers,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Backporting the "stop unloading plugins" change to 5.6

2016-10-13 Thread Sergio Martins 

On 2016-10-12 20:59, Thiago Macieira wrote:

Hello

We've got a number of issues that got fixed in 5.7 by the change that 
made
QFactoryLoader stop unloading plugins (notably, the Network Manager 
bearer
plugin). Given that QtDBus in 5.6 is now heavily threaded, a number of 
new
issues have cropped up. I've managed to fix some, but reports from 
Ubuntu

developers indicate the latest fix only uncovered the next issue.


Hi,


More importantly, this also solves all the QStringLiteral related 
crashes we've been seeing.
We need this in 5.6, but it's too big a behaviour change for an LTS 
release. We need at least a variable to turn it on/off.



Suggestion which me and peppe discussed:

Make it opt-in in 5.6.3 and write in the ChangeLog that there will be a 
behaviour change in 5.6.4.

Make it opt-out in 5.6.4 (bringing it on-par with 5.8).

This gives the user a pre-warning of 3 months, it can still be turned 
off and fixes many crashes.





Regards,
--
Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Backporting the "stop unloading plugins" change to 5.6

2016-10-13 Thread Liang Jian 
Not unloading plugin is really a bad idea.
That will make any memory leak detector report tons of leaks even run a
simplest qt widgets program. Find and fix 'real' memory leak will be much
harder than before.

On Thursday, October 13, 2016, Thiago Macieira 
wrote:

> Em quarta-feira, 12 de outubro de 2016, às 22:28:33 CEST, André Pönitz
> escreveu:
> > On Wed, Oct 12, 2016 at 09:59:06PM +0200, Thiago Macieira wrote:
> > > Hello
> > >
> > > We've got a number of issues that got fixed in 5.7 by the change that
> made
> > > QFactoryLoader stop unloading plugins (notably,
> >
> > Not unloading plugins is not a fix.
>
> No, it's a workaround. But I'm at a loss to fix the current issue.
>
> The issue at hand is that the plugin was unloaded between a slot being
> invoked
> in a queued connection and the object that would receive the event getting
> deleted. When deleting the object, the events queued to it are deleted.
> When
> metacall events are deleted, the parameters stored in it are destroyed. In
> order for QMetaType to destroy such a type, it needs to call the destroying
> functions registered with it.
>
> Since we do allow breaking of ODR because of hidden visibility / DLLs, the
> functions in question may have belonged to the plugin that was unloaded,
> even
> if the type wasn't exclusive to that plugin.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org 
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Multiple Qt branches on Coverity Scan

2016-10-13 Thread Giuseppe D'Angelo 

On 13/10/16 14:35, Marc Mutz wrote:

Will the -lts version start out with its own CIDs or will identical issues
have the same CIDs in both projects? If they're different, we'll have a mess.


The idea was to share the database of CIDs so to keep them in sync. 
That's why it's taking so long to set it up (?). I have no idea how the 
matching between branches is going to work...


HTH,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Multiple Qt branches on Coverity Scan

2016-10-13 Thread Marc Mutz 
On Thursday 13 October 2016 15:11:18 Giuseppe D'Angelo wrote:
> Heads up:
> 
> On 03/10/16 22:46, Giuseppe D'Angelo wrote:
> > I'm going with "lts" and "dev" anyhow, thanks!
> 
> To avoid losing history, we're sticking with the current "qt-project" to
> represent "dev", as apparently it's not possible to rename projects.
> "qt-project-lts" is going to be 5.6. The new branch should be ready soon
> (was told yesterday afternoon, actually), I'll send an email when this
> is done.

Will the -lts version start out with its own CIDs or will identical issues 
have the same CIDs in both projects? If they're different, we'll have a mess.

On that note: I've started using

   Coverity-Id: N

akin to Task-number: in footers of commit messages related to Coverity fixes. 
Please use them, too. Maybe we can highlight them in Gerrit and link to the 
issue directly, even?

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Multiple Qt branches on Coverity Scan

2016-10-13 Thread Giuseppe D'Angelo 

Heads up:

On 03/10/16 22:46, Giuseppe D'Angelo wrote:

I'm going with "lts" and "dev" anyhow, thanks!


To avoid losing history, we're sticking with the current "qt-project" to 
represent "dev", as apparently it's not possible to rename projects. 
"qt-project-lts" is going to be 5.6. The new branch should be ready soon 
(was told yesterday afternoon, actually), I'll send an email when this 
is done.


Related: the "qtbase" and "qtdeclarative" standalone projects have not 
been updated for 2+ years, and they're fully embraced by 
qt-project[-lts], so they're getting removed.


Cheers,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development