Segmentation Fault in qt_cleanup_icon_cache

[gtsu]

I recognize that this might not be officially supported and may therefore be unsolvable, but I will see if anyone has a suggestion in any case.

I have recently been attempting to upgrade a rather old system that uses Qt from Ubuntu 16.04 to Ubuntu 20.04 (and GCC/G++ 10). The version of Qt used by the system is Qt 5.15.2 -- older versions aren't supported at all and don't work with the system, and the rather old code doesn't compile against Qt 6 as is. For the most part, I seem to have gotten the system to compile and run. However, program termination seems to result in a segmentation fault.

The program creates a static object that has a QApplication object member variable. Part of the deconstruction of QApplication involves calling qt_call_post_routines, which calls qt_cleanup_icon_cache, which calls clear. However, as part of these calls, a segmentation fault gets thrown by these functions. The gdb backtrace reads as follows:

Thread 1 "custom_main" received signal SIGSEGV, Segmentation fault.
qt_cleanup_icon_cache () at image/qicon.cpp:124

#0  qt_cleanup_icon_cache() () at image/qicon.cpp:124
#1  0x00007ffff7a70a42 in qt_call_post_routines() () at kernel/qcoreapplication.cpp:336
#2  0x00007ffff6eb9ae6 in QApplication::~QApplication() (this=0x555555574430 <task::Task::get()::task+912>, __in_chrg=<optimized out>) at kernel/qapplication.cpp:711
#3  0x000055555556550d in Custom::~Custom() (this=0x5555555740a0 <parent::Parent::get()::parent>, __in_chrg=<optimized out>) at /usr/include/c++/10/ext/new_allocator.h:89
#4  0x00007ffff551d8a7 in __run_exit_handlers (status=0, listp=0x7ffff56c3718 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:108
#5  0x00007ffff551da60 in __GI_exit (status=<optimized out>) at exit.c:139
#6  0x00007ffff54fb08a in __libc_start_main (main=
    0x7ffff5c88040 <main(int, char**)>, argc=1, argv=0x7fffffffde08, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffddf8) at ../csu/libc-start.c:342
#7  0x000055555555e93e in _start ()

For what it is worth, I did also try testing the same system with the member variable pointing to a dynamic object on the heap and memory management, and I got the same results.

I have also investigated the valgrind output from this segmentation fault. The trace from valgrind reads as follows:

==173807== Invalid read of size 8
==173807==    at 0x5F0A9D0: clear (qcache.h:124)
==173807==    by 0x5F0A9D0: qt_cleanup_icon_cache() (qicon.cpp:124)
==173807==    by 0x4AE9A41: qt_call_post_routines() (qcoreapplication.cpp:336)
==173807==    by 0x53BCAE5: QApplication::~QApplication() (qapplication.cpp:711)
==173807==    by 0x11950C: Custom::~Custom() (Custom.cc:94)
==173807==    by 0x718E8A6: __run_exit_handlers (exit.c:108)
==173807==    by 0x718EA5F: exit (exit.c:139)
==173807==    by 0x716C089: (below main) (libc-start.c:342)
==173807==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==173807== 
OtherName: [BUG] Segmentation fault at 0x0000000000000000

Does anyone have a thought about what could be leading to this segfault and what steps I could try taking to address it?

[SGaist]

Hi,

@gtsu said in Segmentation Fault in qt_cleanup_icon_cache:

The program creates a static object that has a QApplication object member variable.

Can you explain the architecture behind that ?

[gtsu]

I can try, but, unfortunately, the system is old enough that I had nothing to do with the original design, and usually when I ask my seniors why something is built the way it is the answer I get is "because it always has been."

To the best of my understanding, the system is based on a publish-subscribe framework between multiple processes (not threads), all of which utilize the same main function by calling classes derived from the same base class by making use of different object files at linker time. The segfault comes from the process responsible for handling the GUI that displays the status of all of the different processes and the overall system closing. The static object happens to be this process's class that inherits from the base class, and my guess is that the goal of setting the QApplication as a member variable is to avoid forcing all tasks to inherit from Qt, especially those that do not have anything to do with a GUI. I have no explanation for not using multiple inheritance, but I also don't have much experience with Qt to know if inheriting from QApplication is standard practice or not.

As for why the object is static and not dynamic I don't know, but I am guessing somebody thought it would be easier to manage memory that way, since only one instance of the object should exist in the given process in any case.

Is that more or less what you were asking?

[Christian Ehrlicher]

You must not delete a QApplication object in the exit handler - it must be destructed in main(). There is no order of destruction so in your case QApplication tries to access another global static which was cleaned up already and therefore the crash. Fix your code or live with the crash.

[gtsu]

Thank you so much! That was the exact problem. I really want to know how that was never an issue in previous versions of this system, or if the crash was always just ignored.

Is that rule-of-thumb (delete before destruction) common to most Qt and Qwt objects, in case I come across a similar looking failure elsewhere in the system in the future?