[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

TorBrowser 8.0 high cpu usage while idle, in whonix


#1

Edit: added more testing
Edit: replace old versions with new ones

Has anyone else observed this?

An idle torbrowser 8.0 with no addons and just the home page open, running in whonix-ws-14, eventually uses 50%-150% cpu. This occurs after torbrowser is running for a while. Often occurs after resuming from suspend, but suspending is not necessary.

  • TorBrowser 8.0.3/8.5a2: affected
  • TorBrowser 8.0.1 with extensions.torbutton.versioncheck_enabled := false: affected
  • TorBrowser 8.0 manually downloaded from torproject.org running in a debian-9 VM: not affected
  • firefox-60.2.0esr on whonix-14: not affected

strace excerpt:

strace: Process 1236 attached
strace: [ Process PID=1236 runs in x32 mode. ]
strace: [ Process PID=1236 runs in 64 bit mode. ]
write(21, "M", 1)                       = 1
futex(0x77eec4968b08, FUTEX_WAKE_PRIVATE, 1) = 1
gettimeofday({tv_sec=1536281272, tv_usec=371176}, NULL) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=9668, tv_nsec=747749190}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=9668, tv_nsec=747800286}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=9668, tv_nsec=747856121}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=9668, tv_nsec=747912515}) = 0
recvmsg(4, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=29, events=POLLIN}, {fd=33, events=POLLIN}, {fd=53, events=POLLIN}, {fd=71, events=POLLIN}], 6, 0) = 1 ([{fd=33, revents=POLLIN}])
clock_gettime(CLOCK_MONOTONIC, {tv_sec=9668, tv_nsec=748119767}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=9668, tv_nsec=748175956}) = 0
read(33, "\372", 1)                     = 1
clock_gettime(CLOCK_MONOTONIC, {tv_sec=9668, tv_nsec=748289733}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=9668, tv_nsec=748345557}) = 0
recvmsg(4, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=29, events=POLLIN}, {fd=33, events=POLLIN}, {fd=53, events=POLLIN}, {fd=71, events=POLLIN}], 6, 0) = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {tv_sec=9668, tv_nsec=748523610}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=9668, tv_nsec=748579429}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=9668, tv_nsec=748636882}) = 0
gettimeofday({tv_sec=1536281272, tv_usec=372185}, NULL) = 0
ioctl(60, FIONREAD, [0])                = 0
ioctl(60, FIONREAD, [0])                = 0
recvfrom(60, "", 0, 0, NULL, NULL)      = 0
write(21, "M", 1)                       = 1
futex(0x77eec4968b08, FUTEX_WAKE_PRIVATE, 1) = 1
gettimeofday({tv_sec=1536281272, tv_usec=372585}, NULL) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=9668, tv_nsec=749156071}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=9668, tv_nsec=749212254}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=9668, tv_nsec=749268018}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=9668, tv_nsec=749324779}) = 0
recvmsg(4, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=29, events=POLLIN}, {fd=33, events=POLLIN}, {fd=53, events=POLLIN}, {fd=71, events=POLLIN}], 6, 0) = 1 ([{fd=33, revents=POLLIN}])
clock_gettime(CLOCK_MONOTONIC, {tv_sec=9668, tv_nsec=749516152}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=9668, tv_nsec=749573911}) = 0
read(33, "\372", 1)                     = 1
clock_gettime(CLOCK_MONOTONIC, {tv_sec=9668, tv_nsec=749691617}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=9668, tv_nsec=749748225}) = 0
recvmsg(4, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=29, events=POLLIN}, {fd=33, events=POLLIN}, {fd=53, events=POLLIN}, {fd=71, events=POLLIN}], 6, 0) = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {tv_sec=9668, tv_nsec=749928040}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=9668, tv_nsec=749984307}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=9668, tv_nsec=750062799}) = 0
gettimeofday({tv_sec=1536281272, tv_usec=373612}, NULL) = 0
ioctl(60, FIONREAD, [0])                = 0
ioctl(60, FIONREAD, [0])                = 0
recvfrom(60, "", 0, 0, NULL, NULL)      = 0
write(21, "M", 1)                       = 1
futex(0x77eec4968b08, FUTEX_WAKE_PRIVATE, 1) = 1
gettimeofday({tv_sec=1536281272, tv_usec=374010}, NULL) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=9668, tv_nsec=750580684}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=9668, tv_nsec=750636687}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=9668, tv_nsec=750692549}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=9668, tv_nsec=750749224}) = 0
recvmsg(4, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=29, events=POLLIN}, {fd=33, events=POLLIN}, {fd=53, events=POLLIN}, {fd=71, events=POLLIN}], 6, 0) = 1 ([{fd=33, revents=POLLIN}])

strace -c after about 5 seconds:

user@host:~$ ps -A | grep firefox
 1236 ?        03:58:59 firefox.real
user@host:~$ sudo strace -cp 1236
strace: Process 1236 attached
^Cstrace: Process 1236 detached
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
  0.00    0.000000           0      2285           read
  0.00    0.000000           0      2281           write
  0.00    0.000000           0      4567           poll
  0.00    0.000000           0      4536           ioctl
  0.00    0.000000           0      2268           recvfrom
  0.00    0.000000           0      4568      4567 recvmsg
  0.00    0.000000           0      4578           gettimeofday
  0.00    0.000000           0      2296           futex
  0.00    0.000000           0     25513           clock_gettime
------ ----------- ----------- --------- --------- ----------------
100.00    0.000000                 52892      4567 total

#2

Could you try please if you can reproduce this without Tor Browser being involved at all?


#3

Meaning, try to reproduce using Firefox 60.2.0esr on whonix-ws-14?


#4

tatertot:

Meaning, try to reproduce using Firefox 60.2.0esr on whonix-ws-14?

Can do.

But I meant just suspend without anything. Could be sclockadj issue.
That’s why.

To check if sclockadj is running.

ps aux | grep sclockadj

#5

sclockadj (installed at /usr/lib/sdwdate/sclockadj) doesn’t appear in ps.

whonix-installed torbrowser-8.0 on whonix-ws-14 - affected
manually-installed torbrowser-8.0 on debian stretch - can’t reproduce
firefox-60.2.0esr on whonix-ws-14 - can’t reproduce


#6

Can you reproduce this issue while sclockadj does not appear in ps?


#7

Yes. Actually, I’ve never seen sclockadj appear in ps, even though it is installed at /usr/lib/sdwdate/sclockadj


#8

This one?

A nine years unresolved old bug in Firefox but that doesn’t explain why it gets triggered in Whonix only.


#9

Having problems with the same bug on my system. Have this issue when clockadj is running and when it is not. This bug was triggered at VM start so not sure of the reason why this would start all of a sudden


#10

This bug seems to only affect my disp-anon-whonix VMs that use a sys-whonix (based on Template Tor Versioning) as netvm?

When firfox.real CPU starts to spike I switch NetVM to a non-sys-whonix Tor Version VM and the problem is gone. It may have nothing to do with the NetVM that is used. Problem may subside just because NetVM is changed. Or maybe just by coincident.

Note: No problems with any anon-whonix VM that use default sys-whonix VMs as NetVM.


#11

Was searching though Tor trac for High CPU bug reports and came across this older one which was solved by using about:config to toggle extensions.torbutton.versioncheck_enabled to false. Although its a different bug, the solution works for me.

https://trac.torproject.org/projects/tor/ticket/8560


#12

Unfortunately it didn’t work for me : (.


#13

Same problem to me after update. 70-80% CPU usage.
extensions.torbutton.versioncheck_enabled to false don’t help


#14

Having the same issue with different hardware. Running top shows CPU and MEM spike about 20-30 seconds after Tor Browser is started. The spike would be consistent with what I might expect to see when first browsing to a new web page, CPU 90-120% and MEM 30-35%. Like my previous post I was able to fix the issue by typing about:config in the address bar then toggle extensions.torbutton.versioncheck_enabled to false.

It takes about 45 minutes before my laptop starts getting to hot and my fans kick in before I would even know there is an issue so it would not surprise me if more users are having this issue but are not aware of it.


#15

I believe I found the reason that setting extensions.torbutton.versioncheck_enabled to false works for me and no one else. I use a custom script to update my VMs so I always disable qubes-update-check in my VMs since it is not needed. Disabling both qubes-update-check (in sys-whonix) and torbutton.versioncheck (in anon-whonix) is required to prevent high cup in Tor Browser. I’ve tested this quite extensively with newly created sys-whonix and anon-whonix VMs.

Where to submit a bug report? Would this be a Qubes specific issue?

To fix this issue:

  1. Disable qubes-update-check in sys-whonix.

    In a dom0 terminal, run.

    qvm-service -d sys-whonix qubes-update-check

  2. Disble torbutton.versioncheck in anon-whonix Tor Browser.

    In dom0 terminal, run Tor Browser.

    qvm-run anon-whonix torbrowser

    Next, type about:config in Tor Browser address bar.

    Then type extensions.torbutton.versioncheck_enabled in the search bar and “toggle” to false.


#16

Good thought. Perhaps try change from one sys-whonix to another sys-whonix2?

Good question, next question. :wink:

This is a very difficult case.

Since “Disable qubes-update-check in sys-whonix .” is part of the workaround, it could be a Qubes specific issue. But something qubes-update-check does could just be the trigger and it could be a bug in Tor Browser or Firefox.


Commented on https://trac.torproject.org/projects/tor/ticket/8560. Please join if useful.


#17

I might have found something easier. Killing firefox.real in the anon-whonix VM, then restarting Tor Browser can be used as a workaround for that particular session. When this is done the %cpu and %mem are normilized. If using a DispVM users can (1) start a konsole (2) start Tor Browser from the konsole (3)) kill firefox.real (4) start Tor Browser from the konsole. This would allow for killing the process without shutting down the DispVM.

Note: I would suspect killing Tor Browser in the konsole (press Ctrl + C ) would work instead of killing firefox.real. I will find out when I start testing again.

Its odd that changes in both sys-whonix and anon-whonix are needed for a persistent workaround. I wouldn’t be surprised if there was something else that was responsible for this behavior (Tor Browser related)

I haven’t been able to reproduce this in Debian Tor Browser but myabe the right conditions need to be set. I’ll keep going with this and maybe I"ll get lucky. Otherwise it might be best that i not comment on this issue since I might unintentionally say something to get this labeled a Qubes-Whonix bug.