Bug 1755092 - thunderbird segmentation faults when closing after ethernet connection locks up
Summary: thunderbird segmentation faults when closing after ethernet connection locks up
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: thunderbird
Version: 31
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Gecko Maintainer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-09-24 18:33 UTC by Matt Fagnani
Modified: 2020-11-24 16:29 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-24 16:29:03 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Matt Fagnani 2019-09-24 18:33:44 UTC
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/

Comment 1 Ben Cotton 2020-11-03 15:35:50 UTC
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 2 Ben Cotton 2020-11-24 16:29:03 UTC
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.