Fix plugin load failures

[Dmitry A. Kuminov]

Qt core caches plugin information once it tries to load a Qt plugin. If, at this time, the plugin cannot be loaded (i.e. due to missing dependencies among DLLs), an entry saying that the plugin is invalid will be stored in the cache (and taken from there next time the plugin is loaded). This cache is not updated until the plugin DLL timestamp changes (or the cache is manually cleared). As a result, even if later all DLL dependencies are satisfied, Qt will still refuse to use it giving a message like "The file XXX.DLL is not a valid Qt plugin."

This is completely wrong and needs to be fixed. It's a generic Qt problem.

The workaround for this problem is to manually clear the cache entry for the plugin which is stored in %HOME%/.config/Trolltech.ini or just delete this file completely - it will be recreated next time a Qt application starts.

[Dmitry A. Kuminov]

See ​http://svn.netlabs.org/qtapps/ticket/61 for one of the failing cases.

[Dmitry A. Kuminov]

I fixed this in r1151 and r1152 by avoiding caching load attempts that failed due to missing dependencies.

Silvan, a proper error message comes from QPluginLoader now ("File not found (failed module: XXX)") so you can change QPdfView to make it show this message to the end user when it fails to load a plugin.

[Dmitry A. Kuminov]

In general, there is a benefit of caching plugin signatures as it speeds startup of Qt applications (which is quite significant for apps like Qt Creator that use a lot of plugins). However, you have to pay for this with possible problems this ticket is about. I remember now more users complaining that plugins fail to load (e.g. that guy with his Qt Creator startup problem on IRC). With the above fixes, we added a protection against the most common case when dependent DLLs are not found, however it's OS/2 only and there are other potential problems like that.

In order to reduce them even further, in r1154 I also added caching the plugin size together with its timestamp. This allows Qt to revalidate the plugin if its size changes (and not only the timestamp as before). This fixes a scenario where the user gets a plugin DLL which is not complete (e.g. was partially downloaded) and then later replaces it with the complete one (which has the same timestamp). W/o caching its size, we would get exactly the same failing behavior as with missing DLLs before.

Note that it's still possible to trick the plugin loader though. This is if you supply it a DLL with the proper timestamp and size but with a couple of bytes changed (e.g. in a hex editor that doesn't modify the timestamp). But this is definitely hackish (normal users don't do that) so we don't care.

[Dmitry A. Kuminov]

Furthermore, in r1155 I also added caching the error message that describes the reason of the plugin load failure (if any). This allows applications that try to load broken plugins that were already attempted before show the real error message (which was a cause of the failure) instead of the default one (which may simply not match it).

Given all the above fixes, the plugin load feedback should be much more informative to the end user and hence help him solve the problem. Enough with this for now.

[Silvan Scherrer]

Milestone renamed