Description of problem:

I've seen a few segmentation faults when closing thunderbird up to 68.1.0-1 in F31. My thunderbird profile is set to connect to an IMAP server. My ethernet connection has frequently locked up related to a kernel timeout of the transmit queue reported at https://bugzilla.redhat.com/show_bug.cgi?id=1733837
These connection lockups often occur when downloading files greater than 50 MB, though they can also occur when browsing normally. When the connection lockups happened, then I started thunderbird on X, thunderbird tried to connect to the IMAP server but couldn't. The password popup didn't appear as normally. When I closed thunderbird during this attempted connection to the IMAP server, segmentation faults occurred with traces like the following from coredumpctl gdb

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/lib64/thunderbird/thunderbird'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  raise (sig=sig@entry=11) at ../sysdeps/unix/sysv/linux/raise.c:50
50        return ret;
[Current thread is 1 (Thread 0x7f0fb7b82700 (LWP 2575))]

(gdb) bt full
#0  raise (sig=sig@entry=11) at ../sysdeps/unix/sysv/linux/raise.c:50
        set = 
            {__val = {0, 22, 1, 32, 140725573372384, 7268823318927907840, 21, 139705941262160, 139705991828896, 139706029155014, 1, 139706027195496, 101, 0, 0, 0}}
        pid = <optimized out>
        tid = <optimized out>
#1  0x00007f0fd3007f03 in nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*)
    (signo=11, info=<optimized out>, context=0x7f0fb7b818c0)
    at /usr/src/debug/thunderbird-68.1.0-1.fc31.x86_64/toolkit/profile/nsProfileLock.cpp:165
        unblock_sigs = {__val = {1024, 0 <repeats 15 times>}}
        oldact = <optimized out>
#2  0x00007f0fd387f56a in WasmTrapHandler(int, siginfo_t*, void*)
    (signum=11, info=0x7f0fb7b819f0, context=0x7f0fb7b818c0)
    at /usr/src/debug/thunderbird-68.1.0-1.fc31.x86_64/js/src/wasm/WasmSignalHandlers.cpp:962
        previousSignal = <optimized out>
#3  0x00007f0fd88efb20 in <signal handler called> () at /lib64/libpthread.so.0
#4  mozilla::(anonymous namespace)::RunWatchdog(void*) (arg=0x7f0fb2b97268)
    at /usr/src/debug/thunderbird-68.1.0-1.fc31.x86_64/toolkit/components/terminator/nsTerminator.cpp:213
        runtimeService = <optimized out>
        options = 
              {mTuple = {<mozilla::detail::PairHelper<mozilla::(anonymous namespace)::Options*, mozilla::DefaultDelete<mozilla::(anonymous namespace)::Options>, (mozilla::detail::StorageType)1, (mozilla::detail::StorageType)0>> = {<mozilla::DefaultDelete<mozilla::(anonymous namespace)::Options>> = {<No data fields>}, mFirstA = 0x0}, <No data fields>}}
        crashAfterTicks = 63
#5  0x00007f0fd80e6aa4 in _pt_root (arg=0x7f0fb18ee5e0)
    at ../../.././nspr/pr/src/pthreads/ptthread.c:198
        rv = <optimized out>
        thred = 0x7f0fb18ee5e0
        detached = 1
        tid = 2575
#6  0x00007f0fd88e44e2 in start_thread (arg=<optimized out>) at pthread_create.c:479
        ret = <optimized out>
        pd = <optimized out>
        unwind_buf = 
              {cancel_jmp_buf = {{jmp_buf = {139705483536128, -5664866201431675396, 140725573370782, 140725573370783, 140725573370944, 139705483534272, 5727792867889147388, 5727992860575165948}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = 0
#7  0x00007f0fd849c643 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

The segmentation faults appear to involve mozilla::(anonymous namespace)::RunWatchdog(void*) at /usr/src/debug/thunderbird-68.1.0-1.fc31.x86_64/toolkit/components/terminator/nsTerminator.cpp:213
The Shutdown Hang Terminator thread is dealt with in that part of RunWatchdog. CrashReporter::SetMinidumpAnalysisAllThreads(); is called at nsTerminator.cpp:211 to crash the process. thunderbird-68.1.0-1 has the option --disable-crashreporter. thunderbird might've been trying to call the crash reporter which was disabled.

(gdb) list /usr/src/debug/thunderbird-68.1.0-1.fc31.x86_64/toolkit/components/terminator/nsTerminator.cpp:213
208         }
209
210         // Shutdown is apparently dead. Crash the process.
211         CrashReporter::SetMinidumpAnalysisAllThreads();
212
213         MOZ_CRASH("Shutdown too long, probably frozen, causing a crash.");
214       }
215     }


Version-Release number of selected component (if applicable):
glibc-0:2.30-4.fc31.x86_64
nspr-0:4.22.0-1.fc31.x86_64
thunderbird-0:68.1.0-1.fc31.x86_64
kf5-kwayland-0:5.61.0-1.fc31.x86_64
plasma-desktop-0:5.16.4-1.fc31.x86_64
qt5-qtwayland-0:5.12.4-7.fc31.x86_64


How reproducible:
I've seen this crash 5-6 times from thunderbird-60.8.0-1.fc31 to 68.1.0-1.fc31.


Steps to Reproduce:
1. Boot F31 KDE Plasma spin installation with kwin-wayland and its dependencies installed, fully updated with updates-testing enabled
2. Log in to Plasma on Wayland from sddm
3. Make an ethernet connection lock up by downloading files >50 MB until it happens. This connection lockup might be specific to certain ethernet cards.
3. Start thunderbird on X
4. Configure thunderbird to connect to an IMAP server
5. Close thunderbird
6. Start thunderbird on X
7. Close thunderbird as it is trying to connect to an IMAP server

Actual results:
thunderbird segmentation faults when closing after ethernet connection locks up

Expected results:
No crashes would happen.

Additional info:

The first crash with this trace I have in coredumpctl was from July 27 with thunderbird-60.8.0-1.fc31. I tried to report a crash of thunderbird-60.8.0-2.fc31.x86_64 with this trace using gnome-abrt, but I got the error "The release 'fedora-31-x86_64' is not supported by the Retrace server". I reported that error at https://bugzilla.redhat.com/show_bug.cgi?id=1744846 
The FAF link for that crash is https://retrace.fedoraproject.org/faf/reports/2348767/