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 [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
