Shulou(Shulou.com)06/03 Report--

How to solve the problem of QT memory leak, I believe that many inexperienced people do not know what to do. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

01 preface

A few days ago, the project conducted an initial code review. At the meeting, the leader pointed out some code that may cause memory leaks, as shown in the following figure:

The pLayout in the figure does not specify any parent objects when new, and there is no delete operation on pLayout in the destructor of MainWindow, which means that the memory space requested for pLayout has not been released during the program run. In fact, there are many such "hidden dangers" in the project code: the member variable of a singleton class does not specify a parent object when new, and a member of a static class does not specify a parent object when new.

Why are these "hidden dangers" not exposed when the program is running? Based on this doubt, I have studied the semi-automatic memory management of QT, and verified the results with experiments, and now record the analysis process.

02 QT semi-automatic memory management essentials

An object of QObject and its derived classes, if its parent is not 0, will destruct the object when its parent is destructed

For objects of QWidget and its derived classes, you can set the Qt::WA_DeleteOnClose flag bit (the object is destructed when close)

The object of the QAbstractAnimation derived class, you can set the QAbstractAnimation::DeleteWhenStopped

QRunnable::setAutoDelete (), MediaSource::setAutoDelete ()

Parent-child relationship: parent object, child object, parent-child relationship. This is unique in Qt, has nothing to do with class inheritance, and passes parameters related to parent (base class, derived class, or parent class, subclass, which is for derived systems, independent of parent)

03 detailed explanation of the experimental process

Practical examples of memory leakage and improvement of heap space

Inherits the Test class of the QWidget class, allocates memory to it through new, does not set the WA_DeleteOnclose property and has no delete after use

Experimental results: after closing the testWidget window, the destructor is not called to print "test delete" information. The memory space requested by testWidget is not freed until the end of the program.

Improved method A

Set the Qt::WA_DeleteOnClose property for the testWidget window

Experimental result: after closing the testWidget window, the destructor is called and the memory is freed.

Improved method B

The Qt::WA_DeleteOnClose property is not set, but after new finishes testWidget, the delete function of testWidget is called before the program exits.

Experimental result: after closing the testWidget window, the destructor is called and the memory is freed.

Experimental conclusion: objects of QWidget and its derived classes can set the Qt::WA_DeleteOnClose flag bit (the object will be destructed when close occurs) or manually delete to free memory.

The memory practice instance of stack space does not use new, allocates stack space for testWidget, does not set the Qt::WA_DeleteOnClose property, and does not manually delete

Experimental result: when the window is closed, the destructor of testWidget is called, and the memory is freed.

TestWidget does not use new to create, directly suggest the object in the stack space, but set the Qt::WA_DeleteOnClose property or use the delete & testWidget

Experimental result: the program crashed and made an error the first time I tried delete testWidget

Experimental conclusion: the address assigned on the delete stack will go wrong.

A practical example of parent object and child object destructing sets the parent object of testWidget to mainwindow

Experimental results: after the window is closed, the destructing information is printed normally. Before the program exits, free up testWidget space, and then release mainwindow space (both are allocated to stack space)

Adjust the construction order of mainwindow and testWidget

Experimental result: program crashes

Analyze the reason: when mainwindow is destructed, its sub-object testWidget will also be destructed, but testWidget is allocated to the stack space, and the space on the delete stack will go wrong.

Assign testWidget to the heap, specify that the parent object is mainwindow, and delete mainwindow before the program exits

Experimental results: when delete mainwindow, testWidget will also be delete

Take testWidget as a member of mainwindow, but do not specify a parent object at construction time, and delete mainwindow in the main function

Experimental result: only mainwindow is destructed before the application exits

Experimental conclusion:

Destructors always appear at the end of the object's lifetime, and static objects are destructed at the end of the program.

The relationship between object construction and destruction is the relationship between on-stack and out-of-stack in the stack data structure.

The child of the parent object is specified, and when the parent object is destructed, it is also destructed.

Practical example of memory space allocated by Malloc

Create a new malloc_class, take malloc_class as a member of mainwindow, apply for 500m of memory with malloc in the constructor of mallocClass, place a button in mainwindow, click button to delete malloc_class, and see if 500m of memory has been freed in the task manager. For the new operation of malloc_class, two scenarios were tested:

When new malloc_class does not specify a parent object, new malloc_class specifies that its parent object is mainwindow

Experimental results: for the same result in both cases, click button, and after delete testWidget, the 500m space applied in testThread is not released.

Guess whether it is because the space of malloc does not specify a parent object, it is whimsical to test another situation: when creating malloc_class directly, use malloc to allocate memory for it, and then delete malloc_class in the slot function of button

Experimental result: the program crashed.

According to the reference materials, malloc can only allocate memory for POD type data (a class or structure can keep the data unchanged after a binary copy, specifically explain the self-check data), and the other must allocate memory with new. The Malloc function does not call the constructor when it allocates memory space, and the free function does not call the destructor when it reclaims the space.

Experimental conclusion: the memory space allocated by malloc has to be managed by itself, which has nothing to do with the synchronous deconstruction of QT parent and child objects. That is to say, it should be clear again that only objects that specify the parent object and are based on the QObject base class will be destructed synchronously.

Note: the space of malloc is only a virtual memory. You must initialize or write data in order to reflect the physical memory.

For objects that are not resident in the application, you should be accustomed to assigning a parent object to it, or manual delete; after use, even if the operating system releases the memory used by the resident object in the application, even if the operating system releases its memory after the end of the application, it is not recommended that casual new do not have parent objects. In short, form the good habit of strictly dealing with memory allocation and releasing memory, know which memory you use when coding, when you need to release it, and pay attention to the memory occupancy of the program from time to time.

After reading the above, do you know how to solve the problem of QT memory leak? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.