[Interest] QT plugins memory footprint and the debugger

Thiago Macieira thiago.macieira at intel.com
Thu Nov 10 12:11:02 CET 2016


On sábado, 29 de outubro de 2016 20:46:28 CST Martin schouwenburg wrote:
> 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.

Can you provide the backtrace of the throw point?

Is it coming from qlibrary.cpp function findPatternUnloaded? It could be coming 
from here:

    filedata = (char *) file.map(0, fdlen);
    if (filedata == 0) {
        // try reading the data into memory instead
        data = file.readAll();

That readAll() does allocate a block for the entire file into memory.

Ulf's suggestion for splitting the debug info into a separte file helps, since 
it will be a smaller file to be loaded.

But I have to ask: why did the memory mapping fail? Can you run the system 
call inspector tool and find out what error condition was generated after the 
CreateFileMapping call?

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




More information about the Interest mailing list