Qt Applications gets killed automatically by the kernel

  • I am running a Qt application on ARM Cortex V7 processor. It gets killed by the kernel after running for ~5 to 6 hours.

    When I run the Valgrind to check memory leak (for desktop application), it gives the following summary:

    ==8447== LEAK SUMMARY:
    ==8447== definitely lost: 8,804 bytes in 1,063 blocks
    ==8447== indirectly lost: 32 bytes in 1 blocks
    ==8447== possibly lost: 700,808 bytes in 6,220 blocks
    ==8447== still reachable: 23,136,092 bytes in 172,744 blocks
    ==8447== of which reachable via heuristic:
    ==8447== length64 : 4,904 bytes in 80 blocks
    ==8447== newarray : 573,944 bytes in 1,910 blocks
    ==8447== multipleinheritance: 274,552 bytes in 792 blocks
    ==8447== suppressed: 0 bytes in 0 blocks
    ==8447== For counts of detected and suppressed errors, rerun with: -v
    ==8447== Use --track-origins=yes to see where uninitialised values come from
    ==8447== ERROR SUMMARY: 995 errors from 989 contexts (suppressed: 0 from 0)

    On further investigation, it seems that the leak detected by the tool are primarily associated with Qt libraries and not the application itself.

    I could not run Valgrind on ARM application. I tried running Valgrind directly on target device and using QEMU to check for leak but could not due to technical difficulties.

    The system resource status obtained (using top) while application runs is :
    Mem: 96832K used, 411068K free, 204K shrd, 0K buff, 19444K cached
    CPU: 8% usr 45%sys 0%nic 45% idle 0%io 0% irq 0%sirq
    Load average: 0.56 0.24 0.22 1/60 7515

    After running for 5 hours:
    The memory resource hovers around 97MB while the application is running. The memory usage does not increase drastically.
    The CPU load increases to 10% usr, 51% sys and 38% idle time.
    It is a single core processor, the load averages are: 1.15 1.29 1.26 3/60 20677

    The system resource status obtained (using top) while application is NOT running is :
    Mem: 74192K used, 433708K free, 204K shrd, 0K buff, 19440K cached
    CPU: 0% usr 0%sys 0%nic 99% idle 0%io 0% irq 0%sirq
    Load average: 0.00 0.01 0.17 1/56 3817

    The meminfo of the processor is:
    MemTotal: 507900 KB
    MemFree: 411328 KB
    MemAvailable: 424264 KB

    Please advice on the reasons the qt application could be killed by the kernel. The kernel remains alive after killing the applications.

    The approach I am currently using to the mask individual functions to identify the cause. Is there is any other way.

  • Lifetime Qt Champion


    Are you doing dynamic memory allocation in your application ? If so are these properly released ?
    Are you allocating one off QObject base classes objects with a parent rather than deleting them when not used anymore ?

  • Thanks for replying.

    Currently, dynamic memory allocation is used to create an object of hardware interface I2C bus, I2C device and A/D converter. The class is instantiated once and the object is created once.

                 _i2c_bus = new I2CBus(0);

    This object is not released. Will this create problem?

  • Hi, thanks. I confirmed that all the QObject base classes are set with a parent so that they are deleted when the parent is deleted.

  • Qt Champions 2018

    @Vinitha-P What is the actual error/signal if your app is terminated?

  • Lifetime Qt Champion

    Are any of these objects created repeatedly ?

  • Update: Solved

    The kernel does not flag any specific error message. 

    However, got a breakthrough. Found that the application works well when the unit is offline. The application gets killed only when the unit goes online.

    Identified a missed boundary condition when the application queues messages to send on the QTcpSocket.

    Thanks for supporting. Really appreciate your guidance.

  • Lifetime Qt Champion

    Glad you found out and thanks for sharing !

    Since you have it working now, please mark the thread as solved using the "Topic Tools" button so that other forum users may know a solution has been found :)

Log in to reply

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.