Tag: Memory Leaks

The ubiquity of memory leaks in GUI applications.

When I was studying C++ as an Independent Student, we were taught that, as a good programming practice, we should always delete any objects which we had created with the ‘new’ allocator, including, to do so in the destructor of any objects, which created those members in their constructor. Just to define a little bit, what this means, I need to state some facts:

  1. In C++, we can declare objects to exist as such, without using ‘new’, and without initializing object pointers to point to them. When we do so, they are allocated on the stack, their constructors are called in turn, and, when our function call returns, the compiler makes sure that the stack is cleared, at which point the compiler also makes sure that the destructor of such objects is called automatically. In much programming, including GUIs that we build with Qt5, this is considered to be the less-favoured way to do it by default…
  2. As an alternative, we can declare a pointer to a class object to exist. This pointer could reside on the stack, or, it could be a member of the class, and thus, be a property of each object. Regardless of where this pointer has been put, we call ‘new’ to create a new object, and the address returned by ‘new’ is stored in the pointer, by our own explicit code, either in the constructor if the pointer is a class member, or elsewhere if the pointer has been created in the middle of a function-call.
  3. The pointer, a member of the class, might just receive an address from someplace else, thus pointing to an object that was allocated by a different object, in which case it’s the responsibility of the object that originated the pointer’s address, also to destruct the object it points to… This can lead to issues because, if the object that created the object being deleted does so, the other object will still hold an address, which does not get updated (at least, using plain-old C++ pointers, not, smart-pointers). And then, such a copied address might erroneously be used again, creating nasty error messages and crashes.

The problem with scenario (2) above is, that even though the pointer will get removed eventually, during program execution, the object that it points to, will remain by default, unless we call ‘delete’ on the pointer, in which case the destructor will be called on the object pointed to, and then, the space the object occupied is deallocated. There are finer points to how all this should be done, which are taught in C++ programming, and which I will not get into here. But a point which I want to make in this posting is that, when using certain GUI libraries, including Qt5, the programmer is creating many C++ objects, including widgets, layout managers, labels, QString objects, and eventually also, brief message-boxes…

The programming style encourages sloppy programming, in which not all objects that have been created, are also destructed and deallocated eventually. Admittedly, I have also fallen victim to this, in recent exercises I assigned myself, outside any formal learning environment. And of course, always conscious of the possibility that I could be making mistakes, I have found several.

The lessons I was given formally taught us, to be so thorough in deallocating, that we should even do so when our program quits. This is good form. But, when creating my Qt5 projects, I have not been doing this. Instead, what I’ve been doing, is to distinguish between two types of memory leaks:

  1. Objects that are not deleted when the program quits, meaning that my main application window possesses a destructor which does nothing,
  2. Objects that will need to be deleted, because they were members (properties) of other objects, which might be specialized windows of my application, or which might otherwise be created and deleted many times, during one execution of the application.

 

(Updated 9/03/2020, 14h20… )

Continue reading The ubiquity of memory leaks in GUI applications.

Another possible reason, why my Google Pixel C might have started crashing.

One of the facts which I posted about recently was, that My Google Pixel C Tablet had started crashing, roughly every one or two months. Because I haven’t really installed any new software on it, and because the most recent System Update took place sometime in mid-2019, I had assumed that the recent malfunctions could be due to some sort of hardware problem.

The fact that this tablet, which I only bought in 2017, was starting to become unstable, was partially also, why I have recently acquired a Samsung Galaxy Tab S6 tablet, as an eventual replacement.

But, there is in fact another possible explanation, for the crashes of the Pixel C. Until 2019, that tablet had received System Updates roughly once every month. It might just be that, due to many memory leaks, that tablet really needs to be rebooted once per month, and if nothing else, System Updates also resulted in soft reboots. The failure to perform any soft reboots, may be what’s leading to hard reboots. Only, hard reboots are dangerous, because too many of them can lead to file system corruption.

In that regard, I’m hoping that the new Tab S6, which has Android 10 installed, will offer a possible preventive measure, in the fact that it can be scheduled in advance, to reboot automatically, let’s say once per week. If that feature works out as expected, then the tablet in question may indeed last longer than the Pixel C did.

Really, I think it strange, that an Android tablet would crash – or hard-boot – because it was not soft-booted for more than a month. After all, my phones, also being Android devices, have usually been able to run for more than 2 months, without requiring any reboots, and when those finally do receive a soft-boot, it’s part of their System Update.

Dirk