[QGIS-Developer] Should --noplugins disable provider plugins as well ?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[QGIS-Developer] Should --noplugins disable provider plugins as well ?

Sandro Santilli-4
While chasing a [crash at startup](https://github.com/qgis/QGIS/issues/31350)
I found that the --noplugins commandline switch does not prevent QGIS
from loading provider plugins from the plugins directory.

This mail is to ask if you think it should skip those plugins as well.

In my case a set of old/invalid plugins resulted in such crash.

So, what do you think, should I enhance --noplugins to skip those
loads as well ?

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   https://strk.kbt.io/services.html
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Should --noplugins disable provider plugins as well ?

Alessandro Pasotti-2


On Tue, Sep 17, 2019 at 3:59 PM Sandro Santilli <[hidden email]> wrote:
While chasing a [crash at startup](https://github.com/qgis/QGIS/issues/31350)
I found that the --noplugins commandline switch does not prevent QGIS
from loading provider plugins from the plugins directory.

This mail is to ask if you think it should skip those plugins as well.

In my case a set of old/invalid plugins resulted in such crash.

So, what do you think, should I enhance --noplugins to skip those
loads as well ?


I think that the root of the confusion is that we call "plugins" three different objects:
- python plugins
- data providers
- C++ plugins

I think that --noplugins should only skip python (and C++?) plugins and frankly I don't see a use case for not loading data providers.


--
Alessandro Pasotti
w3:   www.itopen.it

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Should --noplugins disable provider plugins as well ?

Matthias Kuhn 🌍
On 9/17/19 4:05 PM, Alessandro Pasotti wrote:


On Tue, Sep 17, 2019 at 3:59 PM Sandro Santilli <[hidden email]> wrote:
While chasing a [crash at startup](https://github.com/qgis/QGIS/issues/31350)
I found that the --noplugins commandline switch does not prevent QGIS
from loading provider plugins from the plugins directory.

This mail is to ask if you think it should skip those plugins as well.

In my case a set of old/invalid plugins resulted in such crash.

So, what do you think, should I enhance --noplugins to skip those
loads as well ?


I think that the root of the confusion is that we call "plugins" three different objects:
- python plugins
- data providers
- C++ plugins

I think that --noplugins should only skip python (and C++?) plugins and frankly I don't see a use case for not loading data providers.

Agreed.

QGIS is still pretty powerful without plugins. Whereas QGIS is pretty much useless without providers.

Broken plugins are quite common. Broken providers something that only ever happens on a few dev machines.

I think disabling providers would turn something that is currently a last resort backup plan into a "break my QGIS completely" option.

If anything, a --noproviders option could be added, but I wonder if it's really worth the effort.

Best regards
Matthias


_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Should --noplugins disable provider plugins as well ?

Sandro Santilli-4
On Tue, Sep 17, 2019 at 04:19:14PM +0200, Matthias Kuhn wrote:
> On 9/17/19 4:05 PM, Alessandro Pasotti wrote:
> >
> > I think that --noplugins should only skip python (and C++?) plugins and
> > frankly I don't see a use case for not loading data providers.
>
> QGIS is still pretty powerful without plugins. Whereas QGIS is pretty much
> useless without providers.

The use case would be this one I'm reporting: QGIS crashes, and users
are asked to run it in a "simplified" way to check if the crash is due
to some plugins.

> If anything, a --noproviders option could be added, but I wonder if it's
> really worth the effort.

There was another bug report for startup-crash which was filed
on May 21 2019 and never fixed (https://github.com/qgis/QGIS/issues/29930)

Anything that can improve debugging could be useful ?

--strk;
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Should --noplugins disable provider plugins as well ?

Matthias Kuhn 🌍
On 9/17/19 4:29 PM, Sandro Santilli wrote:
> On Tue, Sep 17, 2019 at 04:19:14PM +0200, Matthias Kuhn wrote:
>> On 9/17/19 4:05 PM, Alessandro Pasotti wrote:
>>> I think that --noplugins should only skip python (and C++?) plugins and
>>> frankly I don't see a use case for not loading data providers.
>> QGIS is still pretty powerful without plugins. Whereas QGIS is pretty much
>> useless without providers.
> The use case would be this one I'm reporting: QGIS crashes, and users
> are asked to run it in a "simplified" way to check if the crash is due
> to some plugins.

Concerning changing the behaviour of --noplugins, my perception is, that
there's a difference between user installed 3rd party plugins (much more
likely to break the system) and a provider which is always deployed with
QGIS itself and in 99.9% of all the cases rock solid.

>
>> If anything, a --noproviders option could be added, but I wonder if it's
>> really worth the effort.
> There was another bug report for startup-crash which was filed
> on May 21 2019 and never fixed (https://github.com/qgis/QGIS/issues/29930)
As far as I can see, in this report it wasn't even requested to run with
--noplugins.
> Anything that can improve debugging could be useful ?

Let's assume it would have actually been identified that it's a provider
which caused the crash (which already is a question in itself). What
would be the next step? Wouldn't it be easier to ask him to move the
dlls one by one to another place to check if and which provider is
responsible?

I won't block any work on a --noproviders parameter, I just wonder if
it's really worth the effort.

Matthias

>
> --strk;
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Should --noplugins disable provider plugins as well ?

Sandro Santilli-4
On Tue, Sep 17, 2019 at 04:40:57PM +0200, Matthias Kuhn wrote:
>
> Concerning changing the behaviour of --noplugins, my perception is, that
> there's a difference between user installed 3rd party plugins (much more
> likely to break the system) and a provider which is always deployed with
> QGIS itself and in 99.9% of all the cases rock solid.

Why am I so unlikely to always be in that 0.1% ? ...

> As far as I can see, in this report it wasn't even requested to run with
> --noplugins.

You're right, Giovanni's hint was to actually _remove_ the plugins:
https://github.com/qgis/QGIS/issues/29930#issuecomment-495908026

> Let's assume it would have actually been identified that it's a provider
> which caused the crash (which already is a question in itself). What would
> be the next step? Wouldn't it be easier to ask him to move the dlls one by
> one to another place to check if and which provider is responsible?

Yes, that's how it was fixed for me.

BTW, I noticed in code that a QGIS_PROVIDER_FILE env variable can be
set to contain a regexp matching provider plugins. If, as you say,
provider plugins are 99.9% shipped with QGIS, how about making that
file-pattern hard-coded to match actual plugins ? Because in my case
I think the crash came from loading a file not containing "provider"
in the name.

With a clean install I get 15 files under plugins/ matching *provider*
and 13 NOT matching it.

--strk;
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Should --noplugins disable provider plugins as well ?

Sandro Santilli-4
In reply to this post by Matthias Kuhn 🌍
On Tue, Sep 17, 2019 at 04:40:57PM +0200, Matthias Kuhn wrote:
>
> Let's assume it would have actually been identified that it's a provider
> which caused the crash (which already is a question in itself). What would
> be the next step? Wouldn't it be easier to ask him to move the dlls one by
> one to another place to check if and which provider is responsible?
>
> I won't block any work on a --noproviders parameter, I just wonder if it's
> really worth the effort.

Effort seems low, using existing support for env variable.
The resulting QGIS is indeed pretty broken, and full of paths to other segfaults
(may be a good journey to take, fixing those ones).

PS: _static_ plugins would still be available...


---8<------------------------------------------------------------

diff --git a/src/app/main.cpp b/src/app/main.cpp
index 8a5465e3c8..c449424016 100644
--- a/src/app/main.cpp
+++ b/src/app/main.cpp
@@ -144,6 +144,7 @@ void usage( const QString &appName )
       << QStringLiteral( "\t[--nologo]\thide splash screen\n" )
       << QStringLiteral( "\t[--noversioncheck]\tdon't check for new version of QGIS at startup\n" )
       << QStringLiteral( "\t[--noplugins]\tdon't restore plugins on startup\n" )
+      << QStringLiteral( "\t[--nodynamicproviders]\tdon't load dynamic providers on startup\n" )
       << QStringLiteral( "\t[--nocustomization]\tdon't apply GUI customization\n" )
       << QStringLiteral( "\t[--customizationfile path]\tuse the given ini file as GUI customization\n" )
       << QStringLiteral( "\t[--globalsettingsfile path]\tuse the given ini file as Global Settings (defaults)\n" )
@@ -649,6 +650,10 @@ int main( int argc, char *argv[] )
         {
           myRestorePlugins = false;
         }
+        else if ( arg == QLatin1String( "--nodynamicproviders" ) )
+        {
+          setenv( "QGIS_PROVIDER_FILE", "hardly-matching-any-name", 1);
+        }
         else if ( arg == QLatin1String( "--nocustomization" ) || arg == QLatin1String( "-C" ) )
         {
           myCustomization = false;

---8<------------------------------------------------------------
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Should --noplugins disable provider plugins as well ?

Matthias Kuhn 🌍
In reply to this post by Sandro Santilli-4
On 9/17/19 4:51 PM, Sandro Santilli wrote:
> On Tue, Sep 17, 2019 at 04:40:57PM +0200, Matthias Kuhn wrote:
>> Concerning changing the behaviour of --noplugins, my perception is, that
>> there's a difference between user installed 3rd party plugins (much more
>> likely to break the system) and a provider which is always deployed with
>> QGIS itself and in 99.9% of all the cases rock solid.
> Why am I so unlikely to always be in that 0.1% ? ...

If we assume that < 0.1% of all QGIS users are developers who compile
themselves that explains the stats ;)

>
> BTW, I noticed in code that a QGIS_PROVIDER_FILE env variable can be
> set to contain a regexp matching provider plugins. If, as you say,
> provider plugins are 99.9% shipped with QGIS, how about making that
> file-pattern hard-coded to match actual plugins ? Because in my case
> I think the crash came from loading a file not containing "provider"
> in the name.

Not sure, I've never played with that. Might make sense. What does the
commit message say from when it was introduced?

But actually, couldn't this existing variable be already used now to
filter providers fine grained without an additional parameter?

Feel free to proceed with a parameter as well :)

Matthias

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Should --noplugins disable provider plugins as well ?

Sandro Santilli-4
On Tue, Sep 17, 2019 at 05:15:10PM +0200, Matthias Kuhn wrote:
>
> Not sure, I've never played with that. Might make sense. What does the
> commit message say from when it was introduced?

not much:

  commit 3b00dc12583ebcd6148a22fa36c61c0e2a18f7bb
  Author: Radim Blazek <[hidden email]>
  Date:   Mon May 11 15:31:29 2015 +0200

      QGIS_PROVIDER_FILE: provider regexp pattern environment variable

Radim: do you remember the rationale for this ?

> But actually, couldn't this existing variable be already used now to filter
> providers fine grained without an additional parameter?

You have a point...

I'm just thinking if we should have that variable default to
*provider*. Is there a use-case for third-party providers that would
break if we hard-coded a pattern ?

--strk;
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Should --noplugins disable provider plugins as well ?

Radim Blazek-2
On Tue, Sep 17, 2019 at 5:23 PM Sandro Santilli <[hidden email]> wrote:
>   commit 3b00dc12583ebcd6148a22fa36c61c0e2a18f7bb
>   Author: Radim Blazek <[hidden email]>
>   Date:   Mon May 11 15:31:29 2015 +0200
>
>       QGIS_PROVIDER_FILE: provider regexp pattern environment variable
>
> Radim: do you remember the rationale for this ?

I don't remember exactly. It seems to be introduced for browser
debugging/development.

Radim
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer