1965713 - Crash in [@ __syscall_cancel_arch]

Status: NEW

(Core :: XPCOM, defect)

Description

[BugBot [:suhaib / :marco/ :calixte]]

Crash report: https://crash-stats.mozilla.org/report/index/84928c8e-96ca-4a83-9c36-a41660250511

Reason: SIGABRT

Top 10 frames of crashing thread:

0  libc.so.6  __syscall_cancel_arch  sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56
1  libc.so.6  __internal_syscall_cancel  nptl/nptl/cancellation.c:49
2  libc.so.6  __futex_abstimed_wait_common64  nptl/nptl/futex-internal.c:57
2  libc.so.6  __futex_abstimed_wait_common  nptl/nptl/futex-internal.c:87
3  libc.so.6  __pthread_cond_wait_common  nptl/nptl/pthread_cond_wait.c:426
3  libc.so.6  pthread_cond_wait@@GLIBC_2.3.2  nptl/nptl/pthread_cond_wait.c:458
4  firefox-bin  mozilla::detail::ConditionVariableImpl::wait  mozglue/misc/ConditionVariable_posix.cpp:106
4  firefox-bin  mozilla::detail::ConditionVariableImpl::wait_for  mozglue/misc/ConditionVariable_posix.cpp:113
5  libxul.so  mozilla::OffTheBooksCondVar::Wait  xpcom/threads/CondVar.h:65
5  libxul.so  mozilla::Monitor::Wait  xpcom/threads/Monitor.h:39

By querying Nightly crashes reported within the last 2 months, here are some insights about the signature:

• First crash report: 2025-03-06
• Process type: Multiple distinct types
• Is startup crash: No
• Has user comments: No
• Is null crash: Yes - 1 out of 18 crashes happened on null or near null memory address

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::XPCOM' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Andrew McCreight [:mccr8]]

I think this is more of a new crash signature variation for ConditionVariableImpl::wait than a new crash.

Comment 3

[Gabriele Svelto [:gsvelto]]

Indeed, it's probably worth ignoring that frame.

Comment 4

[Mr. Beedell, Roke Julian Lockhart (RJLB)]

bugzilla.redhat.com/show_bug.cgi?id=2375067#c14 is an example of when I have encountered this, per #bugzilla.

Comment 5

[Gabriele Svelto [:gsvelto]]

I dug a bit through this crashes and there's something I don't understand: it seems that we're waiting on a condition variable w/ a timeout, the timeout expired and we're now trying to cancel the wait, and this operation triggers a SIGABRT at the point where we invoke the syscall, which is bizarre. Anyway the code around the crashing point looks like this.

Comment 6

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

A thing about crashes sent with kill or similar on Linux is that the si_addr field is not used, but si_pid and si_uid occupy the same space, so the crash report includes the pid of the process that sent the signal as part of the “address”. It also includes, in the raw minidump, the thread IDs for every thread in the process. In this case, the SIGABRT was sent by a different process owned by the same user. I think it might be some kind of external hang monitor that's part of the desktop environment, force-killing Firefox because it got stuck.

Looking at the stack for bp-84928c8e-96ca-4a83-9c36-a41660250511, we got an input event (the end of a touchpad drag maybe?), we're trying to delete a popup window, which sends a sync IPC message to the compositor, which is also in the parent process, so, considering the Compositor thread… I think this could be a deadlock in APZC? Other crashes under this signature might have different causes.

Comment 7

[Gabriele Svelto [:gsvelto]]

Thanks Jed, this is very useful! So the 3e8 address that keeps coming up is really uid 1000 which makes a lot of sense. The comments are all over the place (there's probably 3 or 4 underlying causes) but these must all be crashes triggered by Firefox hanging and being killed by whatever hang-detection service the desktop environment has.

Comment 8

[Gabriele Svelto [:gsvelto]]

Not any desktop environment either. It seems that >90% of these crashes are from users with KDE Plasma on Wayland.

Comment 9

[Alex Franchuk [:afranchuk]]

I'll chime in here to corroborate that KDE Plasma does indeed have its own hang monitor and crash reporter.

Comment 10

[Mr. Beedell, Roke Julian Lockhart (RJLB)]

Attachment: A Screenshot Of KDE Plasma 6's Hang Handler

The crash reporter (drkonqi) is solely utilised for applications distributed by KDE. Though, the OS may hook into it with a myriad of tools (like systemd's coredumpctl, alongside abrt, which consumes its cores, but also monitors crashes for data which it collects, all of which may be invoked alongside drkonqi).

Considering that I most recently encountered this in discuss.kde.org/t/39560/5, which appeared to be an organic example of [Q]DBus being overwhelmed, despite it also occurring in the very different ticket which #c4 cites, I agree that this may generally be a red-herring. However, it definitely occurs in more than hung states.