Regression caused by PR #127 #142

With PR #127 applied, I experience the following when shutting down the computer:

about 15-20 second waiting time with no more windows on the screen, after the shutdown progress bar has disappered.
reproducible SEGv on kalarmd on exit (see backtrace).

Removing the commit gets rid of the issue and reintroducing the commit reinstate the issue. The problem could be in kalarmd code perhaps and the PR just expose it.

Backtrace

#0  __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7ffe3044ed10, rem=rem@entry=0x7ffe3044ed10) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:71
#1  0x00007f64452f1473 in __GI___nanosleep (req=req@entry=0x7ffe3044ed10, rem=rem@entry=0x7ffe3044ed10) at ../sysdeps/unix/sysv/linux/nanosleep.c:25
#2  0x00007f64452f13aa in __sleep (seconds=0) at ../sysdeps/posix/sleep.c:55
#3  0x00007f6446179e73 in TDECrash::startDrKonqi (argv=argv@entry=0x7ffe30450e60, argc=argc@entry=9) at ./tdecore/kcrash.cpp:312
#4  0x00007f644617a1d3 in TDECrash::defaultCrashHandler (sig=<optimized out>) at ./tdecore/kcrash.cpp:229
#5  <signal handler called>
#6  0x00007f6445d39f6f in TQTextCodec::fromUnicode (this=0x55be752ef7b0, uc=...) at codecs/qtextcodec.cpp:1060
#7  0x00007f6445d1aa53 in TQString::local8Bit (this=this@entry=0x7ffe30451580) at tools/qstring.cpp:6265
#8  0x00007f6445d014c6 in tqWarning (msg=msg@entry=0x7f6445db9440 "TQThreadStorage: thread %lx exited after TQThreadStorage destroyed") at tools/qglobal.cpp:553
#9  0x00007f6445cebf58 in TQThreadStorageData::finish (thread_storage=0x55be752f3750) at tools/qthreadstorage_unix.cpp:170
#10 0x00007f6445a79add in TQThreadInstance::finishGuiThread (d=0x55be752db410) at kernel/qthread_unix.cpp:184
#11 0x00007f6445a85d5a in TQCoreApplicationThread::~TQCoreApplicationThread (this=0x7f6445f9eb40 <tqt_main_thread>, __in_chrg=<optimized out>) at kernel/qapplication.cpp:574
#12 0x00007f644525c403 in __cxa_finalize (d=0x7f6445f9ba80) at ./stdlib/cxa_finalize.c:82
#13 0x00007f6445a1eda7 in __do_global_dtors_aux () from /lib/x86_64-linux-gnu/libtqt-mt.so.3
#14 0x00007f6446be6610 in ?? ()
#15 0x00007f6446be80ca in _dl_call_fini (closure_map=0x7ffe30453740, closure_map@entry=0x7f6446be6610) at ./elf/dl-call_fini.c:43
#16 0x00007f6446bebc8e in _dl_fini () at ./elf/dl-fini.c:114
#17 0x00007f644525c955 in __run_exit_handlers (status=0, listp=0x7f64453f1840 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at ./stdlib/exit.c:111
#18 0x00007f644525ca8a in __GI_exit (status=<optimized out>) at ./stdlib/exit.c:141
#19 0x00007f64452456d1 in __libc_start_call_main (main=main@entry=0x55be74780440 <main(int, char**)>, argc=argc@entry=2, argv=argv@entry=0x7ffe30453b68) at ../sysdeps/nptl/libc_start_call_main.h:74
#20 0x00007f6445245785 in __libc_start_main_impl (main=0x55be74780440 <main(int, char**)>, argc=2, argv=0x7ffe30453b68, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe30453b58) at ../csu/libc-start.c:360
#21 0x000055be74780641 in ?? ()

With PR #127 applied, I experience the following when shutting down the computer: 1. about 15-20 second waiting time with no more windows on the screen, after the shutdown progress bar has disappered. 2. reproducible SEGv on kalarmd on exit (see backtrace). Removing the commit gets rid of the issue and reintroducing the commit reinstate the issue. The problem could be in kalarmd code perhaps and the PR just expose it. <details> <summary>Backtrace</summary> ``` #0 __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7ffe3044ed10, rem=rem@entry=0x7ffe3044ed10) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:71 #1 0x00007f64452f1473 in __GI___nanosleep (req=req@entry=0x7ffe3044ed10, rem=rem@entry=0x7ffe3044ed10) at ../sysdeps/unix/sysv/linux/nanosleep.c:25 #2 0x00007f64452f13aa in __sleep (seconds=0) at ../sysdeps/posix/sleep.c:55 #3 0x00007f6446179e73 in TDECrash::startDrKonqi (argv=argv@entry=0x7ffe30450e60, argc=argc@entry=9) at ./tdecore/kcrash.cpp:312 #4 0x00007f644617a1d3 in TDECrash::defaultCrashHandler (sig=<optimized out>) at ./tdecore/kcrash.cpp:229 #5 <signal handler called> #6 0x00007f6445d39f6f in TQTextCodec::fromUnicode (this=0x55be752ef7b0, uc=...) at codecs/qtextcodec.cpp:1060 #7 0x00007f6445d1aa53 in TQString::local8Bit (this=this@entry=0x7ffe30451580) at tools/qstring.cpp:6265 #8 0x00007f6445d014c6 in tqWarning (msg=msg@entry=0x7f6445db9440 "TQThreadStorage: thread %lx exited after TQThreadStorage destroyed") at tools/qglobal.cpp:553 #9 0x00007f6445cebf58 in TQThreadStorageData::finish (thread_storage=0x55be752f3750) at tools/qthreadstorage_unix.cpp:170 #10 0x00007f6445a79add in TQThreadInstance::finishGuiThread (d=0x55be752db410) at kernel/qthread_unix.cpp:184 #11 0x00007f6445a85d5a in TQCoreApplicationThread::~TQCoreApplicationThread (this=0x7f6445f9eb40 <tqt_main_thread>, __in_chrg=<optimized out>) at kernel/qapplication.cpp:574 #12 0x00007f644525c403 in __cxa_finalize (d=0x7f6445f9ba80) at ./stdlib/cxa_finalize.c:82 #13 0x00007f6445a1eda7 in __do_global_dtors_aux () from /lib/x86_64-linux-gnu/libtqt-mt.so.3 #14 0x00007f6446be6610 in ?? () #15 0x00007f6446be80ca in _dl_call_fini (closure_map=0x7ffe30453740, closure_map@entry=0x7f6446be6610) at ./elf/dl-call_fini.c:43 #16 0x00007f6446bebc8e in _dl_fini () at ./elf/dl-fini.c:114 #17 0x00007f644525c955 in __run_exit_handlers (status=0, listp=0x7f64453f1840 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at ./stdlib/exit.c:111 #18 0x00007f644525ca8a in __GI_exit (status=<optimized out>) at ./stdlib/exit.c:141 #19 0x00007f64452456d1 in __libc_start_call_main (main=main@entry=0x55be74780440 <main(int, char**)>, argc=argc@entry=2, argv=argv@entry=0x7ffe30453b68) at ../sysdeps/nptl/libc_start_call_main.h:74 #20 0x00007f6445245785 in __libc_start_main_impl (main=0x55be74780440 <main(int, char**)>, argc=2, argv=0x7ffe30453b68, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe30453b58) at ../csu/libc-start.c:360 #21 0x000055be74780641 in ?? () ``` </details>

If kalarmd is killed manually before shutting down, I don't see any issue. So this could perhpas really be a kalarmd problem. On the other hand there was no problem without PR #127, so we can't exclude anything at the moment.

Also there could be other applications that I don't use which may have the same issue perhaps.

Just had a similar crash from Konversation.

hmm... that looks odd... it shouldn't happen... I'll look into it tomorrow.

@blu.256, ~~I suppose konversation crashes on exit as well, right?~~

I can reproduce the crash with konversation, I'll look into it tomorrow.

Ok, I see the problem: those are triggered by TQRegExp objects with static storage duration. The order of destruction happens to be:

TQThreadStorageData::~TQThreadStorageData()
TQRegExp::~TQRegExp() (which resurrects the pointer)
TQCoreApplicationThread::~TQCoreApplicationThread() which crashes because it tries to print a warning when it's already too late for TQStrings to work...

I need to think a bit what to do about it... the fact that TQRegExp::~TQRegExp() accesses a destroyed object is already technically a UB and should be fixed, but I need to see why regexs need to resurrect the engine when being destroyed...

I spent quite a bit of time on this yesterday too. The problem is initiated by TQRegExp's thread storage indeed, nevertheless the bug is in how text codec are used. If we remove local8bit() from within the tqWarning() function, there is no crash and the string gets printed correctly. Therefore I think we don't need to fix TQRegExp but rather the string/codec area.
Will do further investigation today.

I have prepared a working fix but I need to clean up the code and extend it to other parts of TQTextCodec. Will probably create a PR in the evening.

but I need to see why regexs need to resurrect the engine when being destroyed...

I didn't look into this part. Perhaps this is yet another bug.

Proposed fix in PR #143. @blu.256 please test with Konversation if you can.

I suppose we should both: the warning clearly indicates an under-laying issue, but it would be nice to have an actual warning in such cases rather than a crash...

A little test case to reproduce the issue:

#include <ntqapplication.h>
#include <ntqtimer.h>
#include <ntqregexp.h>

int main(int argc, char *argv[])
{
    static TQRegExp re(".");
    TQApplication* a = new TQApplication( argc, argv );
    TQTimer::singleShot(0, a, TQ_SLOT(quit()));
    re.search("foo");
    return a->exec();
}

Solved by PR #143. PR #144 was an alternative proposed solution with reduced scope.