Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#986027: firefox: WebExtensions process sometimes consumes 100% CPU indefinitely on Firefox 87

118 views
Skip to first unread message

Yuya Nishihara

unread,
Mar 28, 2021, 3:00:03 AM3/28/21
to
Package: firefox
Version: 87.0-1
Severity: normal

Dear Maintainer,

After upgrading to Firefox 87, I've sometimes seen one of the firefox
contentproc consumes 100% CPU usage indefinitely after start. Killing that
process appears to terminate all of the extensions, and firefox goes back
to normal by reenabling them in "Add-ons Manager" page.

This problem doesn't always occur. I have 3 extensions enabled, which were
installed from the apt repository:

webext-privacy-badger
webext-treestyletab
webext-ublock-origin-firefox

If I disabled one of them, the problem became less likely to occur:

(On Wayland)
enabled extensions reproduced / trials
--------------------------------------------- -------------------
privacy-badger 0 / 30
treestyletab 0 / 30
ublock-origin 4 / 30
privacy-badger + treestyletab 4 / 30
privacy-badger + treestyletab + ublock-origin 21 / 30

Step to reproduce (on Wayland):

$ mkdir /tmp/home
$ HOME=/tmp/home MOZ_ENABLE_WAYLAND=1 firefox
... close firefox and rerun ...

The above number is on Wayland. The compositor is Sway. On XWayland, the
problem occurs less frequently, but I have no idea why.

(On XWayland)
enabled extensions reproduced / trials
--------------------------------------------- -------------------
privacy-badger + treestyletab + ublock-origin 2 / 90

Step to reproduce (on XWayland):

$ mkdir /tmp/home
$ (unset WAYLAND_DISPLAY; unset MOZ_ENABLE_WAYLAND; HOME=/tmp/home firefox)
... close firefox and rerun ...

Stack trace of the contentproc doesn't provide much information. It looks like
the event loop is spinning indefinitely because new events came in.

(gdb) attach 3818
(gdb) bt
#0 __libc_write (nbytes=1, buf=0x7ffe3ca91717, fd=9) at ../sysdeps/unix/sysv/linux/write.c:26
#1 __libc_write (fd=9, buf=buf@entry=0x7ffe3ca91717, nbytes=nbytes@entry=1) at ../sysdeps/unix/sysv/linux/write.c:24
#2 0x00007fc5cde7790b in nsAppShell::ScheduleNativeEventCallback() (this=<optimized out>) at ./widget/gtk/nsAppShell.cpp:244
#3 0x00007fc5cde0fcc1 in non-virtual thunk to nsBaseAppShell::OnDispatchedEvent() () at ./build-browser/dist/include/nsTSubstring.h:1344
#4 0x00007fc5cb5f5de4 in mozilla::TaskController::EnsureMainThreadTasksScheduled() (this=0x7fc5c85f0090) at ./xpcom/threads/TaskController.cpp:918
#5 mozilla::TaskController::MaybeInterruptTask(mozilla::Task*) (this=0x7fc5c85f0090, aTask=0x7fbe277a8200) at ./xpcom/threads/TaskController.cpp:860
#6 0x00007fc5cb5f957e in mozilla::TaskController::AddTask(already_AddRefed<mozilla::Task>&&) (this=0x7fc5c85f0090, aTask=...) at ./build-browser/dist/include/mozilla/RefPtr.h:280
#7 0x00007fc5cb5f983a in mozilla::TaskController::DispatchRunnable(already_AddRefed<nsIRunnable>&&, unsigned int, mozilla::TaskManager*)
(this=<optimized out>, aRunnable=..., aPriority=3, aManager=0x0) at ./xpcom/threads/TaskController.cpp:508
#8 0x00007fc5cb5f98c4 in mozilla::detail::EventQueueInternal<16ul>::PutEvent(already_AddRefed<nsIRunnable>&&, mozilla::EventQueuePriority, mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator>*)
(this=<optimized out>, aEvent=..., aPriority=<optimized out>, aProofOfLock=..., aDelay=aDelay@entry=0x0) at ./xpcom/threads/EventQueue.cpp:52
#9 0x00007fc5cb6029bd in mozilla::ThreadEventQueue::PutEventInternal(already_AddRefed<nsIRunnable>&&, mozilla::EventQueuePriority, mozilla::ThreadEventQueue::NestedSink*)
(this=0x7fc5c8511030, aEvent=<optimized out>, aPriority=<optimized out>, aSink=0x0) at ./xpcom/threads/ThreadEventQueue.cpp:111
#10 0x00007fc5cb606cdd in mozilla::ThreadEventTarget::Dispatch(already_AddRefed<nsIRunnable>, unsigned int) (this=0x7fc5c8524b80, aEvent=..., aFlags=<optimized out>)
at ./xpcom/threads/ThreadEventTarget.cpp:103
#11 0x00007fc5cb606149 in NS_DispatchToCurrentThread(already_AddRefed<nsIRunnable>&&) (aEvent=...) at ./xpcom/threads/nsThreadUtils.cpp:243
#12 0x00007fc5cb5f5666 in mozilla::SchedulerGroup::InternalUnlabeledDispatch(mozilla::TaskCategory, already_AddRefed<mozilla::SchedulerGroup::Runnable>&&)
(aCategory=<optimized out>, aRunnable=...) at ./xpcom/threads/SchedulerGroup.cpp:94
#13 0x00007fc5cb5f56f4 in mozilla::SchedulerGroup::LabeledDispatch(mozilla::TaskCategory, already_AddRefed<nsIRunnable>&&, mozilla::dom::DocGroup*)
(aCategory=mozilla::TaskCategory::Other, aRunnable=<optimized out>, aDocGroup=0x7fc5c84ad0d0) at ./xpcom/threads/SchedulerGroup.cpp:83
#14 0x00007fc5cc5fd185 in (anonymous namespace)::LabellingEventTarget::Dispatch(already_AddRefed<nsIRunnable>, uint32_t) (this=this@entry=0x7fc5c28c2f40, aRunnable=...,
aRunnable@entry=..., aFlags=aFlags@entry=0) at ./dom/base/DocGroup.cpp:83
#15 0x00007fc5cd32c9e9 in nsIEventTarget::Dispatch(nsIRunnable*, unsigned int) (aFlags=0, aEvent=<optimized out>, this=0x7fc5c28c2f40)
at ./build-browser/dist/include/mozilla/AlreadyAddRefed.h:48
#16 mozilla::(anonymous namespace)::InputStreamCallbackRunnable::Execute(nsIInputStreamCallback*, nsIEventTarget*, mozilla::RemoteLazyInputStream*)
(aCallback=0x7fc5c3ce17c8, aEventTarget=0x7fc5c28c2f40, aStream=<optimized out>) at ./dom/file/ipc/RemoteLazyInputStream.cpp:46
#17 0x00007fc5cd32caf8 in mozilla::RemoteLazyInputStream::OnInputStreamReady(nsIAsyncInputStream*) (this=0x7fc5c3ce0c80, aStream=<optimized out>)
at ./dom/file/ipc/RemoteLazyInputStream.cpp:581
#18 0x00007fc5cb5c606c in nsInputStreamReadyEvent::Run() (this=0x7fbe2772b060) at ./xpcom/io/nsStreamUtils.cpp:94
#19 0x00007fc5cb5f2aaa in mozilla::SchedulerGroup::Runnable::Run() (this=0x7fc5a9ccf520) at ./xpcom/threads/SchedulerGroup.cpp:146
#20 0x00007fc5cb5f8899 in mozilla::RunnableTask::Run() (this=0x7fbe2775fa80) at ./xpcom/threads/TaskController.cpp:472
#21 mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) (this=this@entry=0x7fc5c85f0090, aProofOfLock=...)
at ./xpcom/threads/TaskController.cpp:760
#22 0x00007fc5cb5fa813 in mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&)
(this=this@entry=0x7fc5c85f0090, aProofOfLock=...) at ./xpcom/threads/TaskController.cpp:611
#23 0x00007fc5cb5faa0e in mozilla::TaskController::ProcessPendingMTTask(bool) (this=0x7fc5c85f0090, aMayWait=false) at ./xpcom/threads/TaskController.cpp:395
#24 0x00007fc5cb5faae2 in operator() (__closure=<optimized out>) at ./xpcom/threads/TaskController.cpp:133
#25 mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal()::<lambda()> >::Run(void) (this=<optimized out>)
at ./build-browser/dist/include/nsThreadUtils.h:534
#26 0x00007fc5cb6172ab in nsThread::ProcessNextEvent(bool, bool*) (this=0x7fc5c850c580, aMayWait=<optimized out>, aResult=0x7ffe3ca91ca7) at ./xpcom/threads/nsThread.cpp:1158
#27 0x00007fc5cb605b48 in NS_ProcessNextEvent(nsIThread*, bool) (aThread=<optimized out>, aThread@entry=0x7fc5c850c580, aMayWait=aMayWait@entry=false)
at ./xpcom/threads/nsThreadUtils.cpp:548
#28 0x00007fc5cbbabe4a in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (this=0x7fc5d62a3290, aDelegate=0x7ffe3ca91e50) at ./ipc/glue/MessagePump.cpp:87
#29 0x00007fc5cbb78215 in MessageLoop::RunInternal() (this=<optimized out>) at ./ipc/chromium/src/base/message_loop.cc:335
#30 MessageLoop::RunHandler() (this=<optimized out>) at ./ipc/chromium/src/base/message_loop.cc:328
#31 MessageLoop::Run() (this=<optimized out>) at ./ipc/chromium/src/base/message_loop.cc:310
#32 0x00007fc5cde0ecf8 in nsBaseAppShell::Run() (this=0x7fc5c3de8520) at ./widget/nsBaseAppShell.cpp:137
#33 0x00007fc5cee7a653 in XRE_RunAppShell() () at ./toolkit/xre/nsEmbedFunctions.cpp:902
#34 0x00007fc5cbb78215 in MessageLoop::RunInternal() (this=0x7ffe3ca91e50) at ./ipc/chromium/src/base/message_loop.cc:335
#35 MessageLoop::RunHandler() (this=0x7ffe3ca91e50) at ./ipc/chromium/src/base/message_loop.cc:328
#36 MessageLoop::Run() (this=this@entry=0x7ffe3ca91e50) at ./ipc/chromium/src/base/message_loop.cc:310
#37 0x00007fc5cee7aa4e in XRE_InitChildProcess(int, char**, XREChildData const*) (aArgc=13, aArgv=0x7ffe3ca921e8, aChildData=<optimized out>)
at ./toolkit/xre/nsEmbedFunctions.cpp:733
#38 0x000055dad59c6d17 in content_process_main(mozilla::Bootstrap*, int, char**) (bootstrap=0x7fc5d6233630, argc=15, argv=argv@entry=0x7ffe3ca921e8)
at ./browser/app/../../ipc/contentproc/plugin-container.cpp:57
#39 0x000055dad59c6590 in main(int, char**, char**) (argc=<optimized out>, argv=<optimized out>, envp=0x7ffe3ca92270) at ./build-browser/dist/include/mozilla/UniquePtr.h:290
(gdb) c
Continuing.
[Thread 0x7fc5ad408700 (LWP 3909) exited]
^C
Thread 1 "WebExtensions" received signal SIGINT, Interrupt.
__vdso_clock_gettime (clock=<optimized out>, ts=0x7ffe3ca91660) at arch/x86/include/asm/vdso/gettimeofday.h:78
Download failed: Invalid argument. Continuing without source file debian/build/build_amd64_none_amd64/arch/x86/include/asm/vdso/gettimeofday.h.
78 arch/x86/include/asm/vdso/gettimeofday.h: No such file or directory.
(gdb) bt
#0 __vdso_clock_gettime (clock=<optimized out>, ts=0x7ffe3ca91660) at arch/x86/include/asm/vdso/gettimeofday.h:78
#1 0x00007fc5d66d3b41 in __GI___clock_gettime (clock_id=clock_id@entry=1, tp=tp@entry=0x7ffe3ca91660) at ../sysdeps/unix/sysv/linux/clock_gettime.c:38
#2 0x000055dad5a0f7b1 in ClockTimeNs () at ./mozglue/misc/TimeStamp_posix.cpp:74
#3 mozilla::TimeStamp::Now(bool) (aHighResolution=aHighResolution@entry=true) at ./mozglue/misc/TimeStamp_posix.cpp:186
#4 0x00007fc5cb5f94e2 in mozilla::TimeStamp::Now() () at ./build-browser/dist/include/mozilla/TimeStamp.h:452
#5 mozilla::TaskController::AddTask(already_AddRefed<mozilla::Task>&&) (this=0x7fc5c85f0090, aTask=...) at ./xpcom/threads/TaskController.cpp:344
#6 0x00007fc5cb5f983a in mozilla::TaskController::DispatchRunnable(already_AddRefed<nsIRunnable>&&, unsigned int, mozilla::TaskManager*)
(this=<optimized out>, aRunnable=..., aPriority=3, aManager=0x0) at ./xpcom/threads/TaskController.cpp:508
#7 0x00007fc5cb5f98c4 in mozilla::detail::EventQueueInternal<16ul>::PutEvent(already_AddRefed<nsIRunnable>&&, mozilla::EventQueuePriority, mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&, mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator>*)
(this=<optimized out>, aEvent=..., aPriority=<optimized out>, aProofOfLock=..., aDelay=aDelay@entry=0x0) at ./xpcom/threads/EventQueue.cpp:52
#8 0x00007fc5cb6029bd in mozilla::ThreadEventQueue::PutEventInternal(already_AddRefed<nsIRunnable>&&, mozilla::EventQueuePriority, mozilla::ThreadEventQueue::NestedSink*)
(this=0x7fc5c8511030, aEvent=<optimized out>, aPriority=<optimized out>, aSink=0x0) at ./xpcom/threads/ThreadEventQueue.cpp:111
#9 0x00007fc5cb606cdd in mozilla::ThreadEventTarget::Dispatch(already_AddRefed<nsIRunnable>, unsigned int) (this=0x7fc5c8524b80, aEvent=..., aFlags=<optimized out>)
at ./xpcom/threads/ThreadEventTarget.cpp:103
#10 0x00007fc5cb606149 in NS_DispatchToCurrentThread(already_AddRefed<nsIRunnable>&&) (aEvent=...) at ./xpcom/threads/nsThreadUtils.cpp:243
#11 0x00007fc5cb5f5666 in mozilla::SchedulerGroup::InternalUnlabeledDispatch(mozilla::TaskCategory, already_AddRefed<mozilla::SchedulerGroup::Runnable>&&)
(aCategory=<optimized out>, aRunnable=...) at ./xpcom/threads/SchedulerGroup.cpp:94
#12 0x00007fc5cb5f56f4 in mozilla::SchedulerGroup::LabeledDispatch(mozilla::TaskCategory, already_AddRefed<nsIRunnable>&&, mozilla::dom::DocGroup*)
(aCategory=mozilla::TaskCategory::Other, aRunnable=<optimized out>, aDocGroup=0x7fc5c84ad0d0) at ./xpcom/threads/SchedulerGroup.cpp:83
#13 0x00007fc5cc5fd185 in (anonymous namespace)::LabellingEventTarget::Dispatch(already_AddRefed<nsIRunnable>, uint32_t)
(this=<optimized out>, aRunnable=..., aFlags=<optimized out>) at ./dom/base/DocGroup.cpp:83
#14 0x00007fc5cb5c9c92 in non-virtual thunk to nsInputStreamReadyEvent::OnInputStreamReady(nsIAsyncInputStream*) () at ./xpcom/io/nsStreamUtils.cpp:89
#15 0x00007fc5cb5cf66f in nsPipeEvents::~nsPipeEvents() (this=0x7ffe3ca91920, __in_chrg=<optimized out>) at ./xpcom/io/nsPipe3.cpp:1141
#16 0x00007fc5cb5d34a7 in nsPipeInputStream::AsyncWait(nsIInputStreamCallback*, unsigned int, unsigned int, nsIEventTarget*)
(this=0x7fc5c27061f0, aCallback=0x7fbe2772b0d0, aFlags=1017714976, aRequestedCount=<optimized out>, aTarget=<optimized out>) at ./xpcom/io/nsPipe3.cpp:1424
#17 0x00007fc5cd32f1b9 in mozilla::RemoteLazyInputStream::AsyncWait(nsIInputStreamCallback*, unsigned int, unsigned int, nsIEventTarget*)
(this=0x7fc5c3ce0c80, aCallback=<optimized out>, aFlags=<optimized out>, aRequestedCount=<optimized out>, aEventTarget=0x7fc5c28c2f40)
at ./dom/file/ipc/RemoteLazyInputStream.cpp:454
#18 0x00007fc5cb6e0765 in nsInputStreamPump::EnsureWaiting() (this=this@entry=0x7fc5c3ce17c0) at ./netwerk/base/nsInputStreamPump.cpp:126
#19 0x00007fc5cb6ed82e in nsInputStreamPump::EnsureWaiting() (this=0x7fc5c3ce17c0) at ./netwerk/base/nsInputStreamPump.cpp:114
#20 nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) (this=0x7fc5c3ce17c0, stream=<optimized out>) at ./netwerk/base/nsInputStreamPump.cpp:442
#21 0x00007fc5cd32cbb2 in mozilla::(anonymous namespace)::InputStreamCallbackRunnable::Run() (this=0x7fc5a9ce6370) at ./dom/file/ipc/RemoteLazyInputStream.cpp:54
#22 0x00007fc5cb5f2aaa in mozilla::SchedulerGroup::Runnable::Run() (this=0x7fc5a9ce63a0) at ./xpcom/threads/SchedulerGroup.cpp:146
#23 0x00007fc5cb5f8899 in mozilla::RunnableTask::Run() (this=0x7fc5a9cbf680) at ./xpcom/threads/TaskController.cpp:472
#24 mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) (this=this@entry=0x7fc5c85f0090, aProofOfLock=...)
at ./xpcom/threads/TaskController.cpp:760
#25 0x00007fc5cb5fa813 in mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&)
(this=this@entry=0x7fc5c85f0090, aProofOfLock=...) at ./xpcom/threads/TaskController.cpp:611
#26 0x00007fc5cb5faa0e in mozilla::TaskController::ProcessPendingMTTask(bool) (this=0x7fc5c85f0090, aMayWait=false) at ./xpcom/threads/TaskController.cpp:395
#27 0x00007fc5cb5faae2 in operator() (__closure=<optimized out>) at ./xpcom/threads/TaskController.cpp:133
#28 mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal()::<lambda()> >::Run(void) (this=<optimized out>)
at ./build-browser/dist/include/nsThreadUtils.h:534
#29 0x00007fc5cb6172ab in nsThread::ProcessNextEvent(bool, bool*) (this=0x7fc5c850c580, aMayWait=<optimized out>, aResult=0x7ffe3ca91ca7) at ./xpcom/threads/nsThread.cpp:1158
#30 0x00007fc5cb605b48 in NS_ProcessNextEvent(nsIThread*, bool) (aThread=<optimized out>, aThread@entry=0x7fc5c850c580, aMayWait=aMayWait@entry=false)
at ./xpcom/threads/nsThreadUtils.cpp:548
#31 0x00007fc5cbbabe4a in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (this=0x7fc5d62a3290, aDelegate=0x7ffe3ca91e50) at ./ipc/glue/MessagePump.cpp:87
#32 0x00007fc5cbb78215 in MessageLoop::RunInternal() (this=<optimized out>) at ./ipc/chromium/src/base/message_loop.cc:335
#33 MessageLoop::RunHandler() (this=<optimized out>) at ./ipc/chromium/src/base/message_loop.cc:328
#34 MessageLoop::Run() (this=<optimized out>) at ./ipc/chromium/src/base/message_loop.cc:310
#35 0x00007fc5cde0ecf8 in nsBaseAppShell::Run() (this=0x7fc5c3de8520) at ./widget/nsBaseAppShell.cpp:137
#36 0x00007fc5cee7a653 in XRE_RunAppShell() () at ./toolkit/xre/nsEmbedFunctions.cpp:902
#37 0x00007fc5cbb78215 in MessageLoop::RunInternal() (this=0x7ffe3ca91e50) at ./ipc/chromium/src/base/message_loop.cc:335
#38 MessageLoop::RunHandler() (this=0x7ffe3ca91e50) at ./ipc/chromium/src/base/message_loop.cc:328
#39 MessageLoop::Run() (this=this@entry=0x7ffe3ca91e50) at ./ipc/chromium/src/base/message_loop.cc:310
#40 0x00007fc5cee7aa4e in XRE_InitChildProcess(int, char**, XREChildData const*) (aArgc=13, aArgv=0x7ffe3ca921e8, aChildData=<optimized out>)
at ./toolkit/xre/nsEmbedFunctions.cpp:733
#41 0x000055dad59c6d17 in content_process_main(mozilla::Bootstrap*, int, char**) (bootstrap=0x7fc5d6233630, argc=15, argv=argv@entry=0x7ffe3ca921e8)
at ./browser/app/../../ipc/contentproc/plugin-container.cpp:57
#42 0x000055dad59c6590 in main(int, char**, char**) (argc=<optimized out>, argv=<optimized out>, envp=0x7ffe3ca92270) at ./build-browser/dist/include/mozilla/UniquePtr.h:290


-- Package-specific info:


-- Addons package information

-- System Information:
Debian Release: bullseye/sid
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-5-amd64 (SMP w/16 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firefox depends on:
ii debianutils 4.11.2
ii fontconfig 2.13.1-4.2
ii libatk1.0-0 2.36.0-2
ii libc6 2.31-10
ii libcairo-gobject2 1.16.0-5
ii libcairo2 1.16.0-5
ii libdbus-1-3 1.12.20-2
ii libdbus-glib-1-2 0.110-6
ii libevent-2.1-7 2.1.12-stable-1
ii libffi7 3.3-6
ii libfontconfig1 2.13.1-4.2
ii libfreetype6 2.10.4+dfsg-1
ii libgcc-s1 10.2.1-6
ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1
ii libglib2.0-0 2.66.8-1
ii libgtk-3-0 3.24.24-3
ii libnspr4 2:4.29-1
ii libnss3 2:3.63-1
ii libpango-1.0-0 1.46.2-3
ii libstdc++6 10.2.1-6
ii libvpx6 1.9.0-1
ii libx11-6 2:1.7.0-2
ii libx11-xcb1 2:1.7.0-2
ii libxcb-shm0 1.14-3
ii libxcb1 1.14-3
ii libxcomposite1 1:0.4.5-1
ii libxdamage1 1:1.1.5-2
ii libxext6 2:1.3.3-1.1
ii libxfixes3 1:5.0.3-2
ii libxrender1 1:0.9.10-1
ii procps 2:3.3.17-4
ii zlib1g 1:1.2.11.dfsg-2

Versions of packages firefox recommends:
ii libavcodec58 7:4.3.2-0+deb11u1

Versions of packages firefox suggests:
ii fonts-lmodern 2.004.5-6.1
pn fonts-stix | otf-stix <none>
ii libcanberra0 0.30-7
ii libgssapi-krb5-2 1.18.3-4
ii libgtk2.0-0 2.24.33-1
pn pulseaudio <none>

-- no debconf information

Grégory Mounié

unread,
Apr 26, 2021, 8:20:03 AM4/26/21
to

I have the same troubles with X11 (KDE; linux XXX 5.10.0-6-amd64 #1
SMP Debian 5.10.28-1 (2021-04-09) x86_64 GNU/Linux)

According to perf (perf record -p PID_OF_WebExtensions sleep 5;
hotspot perf.data), the CPU time is spend in

nft_pipapo_avx2_scratch_index [nf_tables] use 50% of the cycles
(What ? netfilter ?)

Grégory

--
G. Mounié - Associate Prof., Univ. Grenoble Alpes (Grenoble-INP/Ensimag)
LIG - Datamove Inria team, off. 440, IMAG building,+33(0)457 421 533, FR

Christoph Anton Mitterer

unread,
Jul 5, 2021, 5:10:04 PM7/5/21
to
Control: forcemerge 986567 986027

Hey.

I think these two are the same, thus merging. Probably #987704 is yet
another duplicate.

Cheers,
Chris.

Erich Schubert

unread,
Sep 28, 2021, 7:00:03 AM9/28/21
to
Apparently, there exists a preliminary fix for this issue.

-------- Forwarded Message --------
Subject: [Bug 1706594] 100% CPU usage on WebExtensions process
Date: Thu, 23 Sep 2021 18:22:36 +0000



*Comment # 32 <https://bugzilla.mozilla.org/show_bug.cgi?id=1706594#c32>
on Bug 1706594 <https://bugzilla.mozilla.org/show_bug.cgi?id=1706594>
from Luca Greco [:rpl] [:luca] [:lgreco] <mailto:lgr...@mozilla.com> at
2021-09-23 11:22:34 PDT *

I just looked to the debian bug report linked from comment 5
</show_bug.cgi?id=1706594#c5>
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986027) and then to
the content of the debian packages for one of the extension mentioned in
that bug and then I realized that the extension installed from these
debian packages are unpackaged and so they should be triggering the
exact same issue that I was able to trigger consistently using the STR
from comment 15 </show_bug.cgi?id=1706594#c15> (where ABP has to also be
loaded as unpacked to trigger the issue consistently).

e.g. the content of thewebext-private-badger one from
packages.ubuntu.com (debian.packages.org seems to don't be able to show
the list of files, but they should be packaged exactly in the same way
from this perspective):

* https://packages.ubuntu.com/hirsute/all/webext-privacy-badger/filelist

This confirms that the attached fix should also be covering the issue
experienced by debian/ubuntu users that are installing extensions from
deb packages instead of installing them from addons.mozilla.org (or by
installing the signed xpi non temporarily).

(I'm also clearing the previously assigned needinfos, I discussed the
proposed approach used in the current version of the attached patch with
Nika over Matrix and we will continue on phabricator).

Christoph Anton Mitterer

unread,
Oct 6, 2021, 11:00:05 AM10/6/21
to
Hey Mike.

Would it be possible to cherry pick the upstream candidate for fix...
maybe at least for some version in experimental?

This issue really seems like a showstopper for everyone using addons.


Cheers,
Chris

Mike Hommey

unread,
Oct 6, 2021, 11:50:02 PM10/6/21
to
The linked upstream fix landed in version 88.0. Unstable has had
versions newer than that for a while. As for firefox-esr, it has
91.2 as of yesterday.

That'd imply this is fixed?

Mike

Christoph Anton Mitterer

unread,
Oct 7, 2021, 12:10:02 AM10/7/21
to
On Thu, 2021-10-07 at 12:38 +0900, Mike Hommey wrote:
> The linked upstream fix landed in version 88.0.

Uhm...? The commit is from 23 days ago, how could it have gone into 88?



> That'd imply this is fixed?

No, right now the issue is still present.


Cheers,
Chris.

Mike Hommey

unread,
Oct 7, 2021, 12:30:03 AM10/7/21
to
On Thu, Oct 07, 2021 at 06:06:48AM +0200, Christoph Anton Mitterer wrote:
> On Thu, 2021-10-07 at 12:38 +0900, Mike Hommey wrote:
> > The linked upstream fix landed in version 88.0.
>
> Uhm...? The commit is from 23 days ago, how could it have gone into 88?

Oh, I misread that bug status. That confirms the day after a covid
vaccine shot is not a good day to do anything.

Mike

Erich Schubert

unread,
Oct 12, 2021, 9:00:03 AM10/12/21
to
A fix is scheduled for Firefox 95 apparently.

https://bugzilla.mozilla.org/show_bug.cgi?id=1706594

https://hg.mozilla.org/mozilla-central/rev/2c21101c4b3b

After removing the webext-* packages and installing the extensions
manually, the issue did not reoccur for me. So if you want a workaround,
uninstall the packaged extensions, and install them via the browser instead.

Regards,
Erich

Paul Wise

unread,
Oct 22, 2021, 11:20:04 AM10/22/21
to
On Sun, 28 Mar 2021 15:41:29 +0900 Yuya Nishihara wrote:

> After upgrading to Firefox 87, I've sometimes seen one of the firefox
> contentproc consumes 100% CPU usage indefinitely after start. Killing that
> process appears to terminate all of the extensions, and firefox goes back
> to normal by reenabling them in "Add-ons Manager" page.

FYI I found a faster way to disable/enable addons:

First in about:config set devtools.chrome.enabled to true.

Then when you want to apply the workaround pres Ctrl+Shift+j, run this:

Components.utils.import("resource://gre/modules/AddonManager.jsm");
AddonManager.getAllAddons().then(addons => addons.forEach(addon => {addon.disable() ; addon.enable()}))

--
bye,
pabs

https://wiki.debian.org/PaulWise
signature.asc

Paul Wise

unread,
Nov 3, 2021, 2:00:08 AM11/3/21
to
On Tue, 12 Oct 2021 14:43:38 +0200 Erich Schubert wrote:

> A fix is scheduled for Firefox 95 apparently.

Since this issue also affects Firefox ESR,
a backport to Firefox ESR 91 would be nice.
signature.asc

Christoph Anton Mitterer

unread,
Dec 11, 2021, 8:20:03 PM12/11/21
to
Control: fixed -1 95.0-1

Hey.

While I had the feeling that this bug already happened less often with
~FF94 (though still far too often ;-) )... it seems (so far at least)
that it's actually no longer occurring with FF95.

So I guess the upstream's fix did the job.


Anyone else still experiencing it in FF95?


Cheers,
Chris.
0 new messages