[Interest] QT plugins memory footprint and the debugger

[Martin schouwenburg]

I am (trying) to upgrade a qtquick application from qt 5.2 to qt 5.7. Now I am running in a bit unexpected problem. The application is quite large and contains 10+ modules that use the QTPluginLoader mechanism to load its functionality. It worked fine under 5.2 but under 5.7 I get memory issues when loading the plugins. Smaller plugins load fine, bigger ones bug out with a bad_alloc. Now I am using the MingGW compiler and this generates debug plugins which can grow quite big, 50+ Mb. Note that the problem disappears when I shrink the size of a plugin (removing functionality) and is happening purely in the qt code. I traced it down to the attempt of the pluginloader to read the whole plugin at once in one chunck of memory at which point it (can) generates a bad_alloc.


I worked around this by dumping the QPluginLoader which resolved these kind of problems. Unofrtunately this moved the problem to QT itself ( at least QT Quick) for now I get :
plugin cannot be loaded for module "QtQuick.Controls": Cannot load library ..\qtquickcontrolsplugind.dll: Not enough storage is available to process this command

Looking at the source of qt, the problem is identical(though it is protected against runaway exceptions). The MinGw debug plugins of qtquick are quite large and use the same mechanism to load plugins. If, as in my case, the initialization of the program allocates considerable memory ( but tbh, not excesively so, there is plenty left) QT (and by extension QT quick) can run into problems; in debug mode, using MinGw. This wasnt the case in 5.2 so I must assume that code of loading plugins was changed in between.

From my own experience ( i work a lot with big raster data sets) I can say that in 32-bits applications allocating blocks of 50 Mb or bigger can sometimes cause problems if you dont use a dedicated allocator

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20161029/3def6c59/attachment.html>