Debian Bug report logs - #848930
kills fellow process if window doesn't have focus

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: kills fellow process if window doesn't have focus

Date: Tue, 20 Dec 2016 16:44:44 -0500

Package: chromium
Version: 55.0.2883.75-1~deb8u1
Severity: normal

I am using the Xmonad window manager. I have my browser in workspace
N. When I am in workspace N+1 and I run "chromium http://example.com",
it takes about 20-30 seconds, then it *kills* the browser in workspace
N and starts a *new* one in workspace N+1.

Here's how the browser is started in workspace N:

$ chromium -g
# Env:
#     LD_LIBRARY_PATH=
#                PATH=/home/anarcat/bin:/home/anarcat/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/sbin:/usr/sbin:/sbin
#            GTK_PATH=
#      CHROMIUM_FLAGS=
/usr/bin/gdb /usr/lib/chromium/chromium -x /tmp/chromiumargs.UxIxak
[...]
(gdb) run
Starting program: /usr/lib/chromium/chromium 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffeb2aa700 (LWP 14507)]
[...]
[14901:14901:1220/161528:ERROR:sandbox_linux.cc(343)] InitializeSandbox() called with multiple threads in process gpu-process. 
[...]

Then, in workspace N+1:

$ chromium -g http://example.com/
[...]
(gdb) run
Starting program: /usr/lib/chromium/chromium http://example.com/
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffeb2aa700 (LWP 14863)]
[New Thread 0x7fffeaaa9700 (LWP 14868)]
[...]
[[...]:ERROR:sandbox_linux.cc(343)] InitializeSandbox() called with multiple threads in process gpu-process. 
[...waits approximately 20 seconds...]

Then in workspace N+1:

Thread [...] (LWP [...]) exited
Program terminated with signal SIGKILL, Killed.
The program no longer exists.
(gdb) [89:89:0100/000000:ERROR:broker_posix.cc(41)] Invalid node channel message

If I switch to the N+1 workspace *before* the 20 seconds timeout, the
URL loads without problems. It looks like the message doesn't get sent
or received untill the window is in focus again.

There seems to be a surprisingly large number of places where chromium
kills stuff with such a SIGKILL, so it's hard to track down exactly
wtf is going on here:

chromium-browser-55.0.2883.75$ grep -r 'kill.*SIGKILL' | wc -l 
73

But I suspect the problem is likely in the "singleton" handling
(chrome/browser/process_singleton_posix.cc) where there is logic to
send a message to an existing process and kill it (with SIGKILL) if it
doesn't answer within a specific timeout (20 attempts in 20 seconds,
coincidentally enough).

I have read parts of the code in that file and everything seems
normal. There's nothing about focus or activity in there. It looks
like the process that is not focused is just suspended and doesn't
answer requests. Here's an strace of workspace N+1:

readlink("/home/anarcat/.config/chromium/SingletonSocket", "/tmp/.org.chromium.Chromium.J1pI"..., 4096) = 50
readlink("/home/anarcat/.config/chromium/SingletonCookie", "11631173611837275778", 4096) = 20
readlink("/tmp/.org.chromium.Chromium.J1pIRs/SingletonCookie", "11631173611837275778", 4096) = 20
connect(47, {sa_family=AF_LOCAL, sun_path="/tmp/.org.chromium.Chromium.J1pIRs/SingletonSocket"}, 110) = 0
readlink("/tmp/.org.chromium.Chromium.J1pIRs/SingletonCookie", "11631173611837275778", 4096) = 20
setsockopt(47, SOL_SOCKET, SO_SNDTIMEO, "\24\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 16) = 0
getcwd("/home/anarcat", 4096)           = 14
write(47, "START\0/home/anarcat\0/usr/lib/chr"..., 107) = 107
shutdown(47, SHUT_WR)                   = 0
select(48, [47], NULL, NULL, {20, 0}[21172:21195:1220/164251:ERROR:nss_util.cc(809)] After loading Root Certs, loaded==false: NSS error code: -8018
[21211:21211:1220/164251:ERROR:sandbox_linux.cc(343)] InitializeSandbox() called with multiple threads in process gpu-process. 
)   = 0 (Timeout)
readlink("/home/anarcat/.config/chromium/SingletonLock", "angela-19326", 4096) = 12
uname({sys="Linux", node="angela", ...}) = 0
unlink("/home/anarcat/.config/chromium/SingletonLock") = 0
open("/proc/19326/stat", O_RDONLY)      = 61
fstat(61, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f29f7ea8000
read(61, "19326 (chromium) S 19289 5141 51"..., 65536) = 360
read(61, "", 64512)                     = 0
read(61, "", 65536)                     = 0
close(61)                               = 0
munmap(0x7f29f7ea8000, 4096)            = 0
madvise(0x14807f7d000, 921600, MADV_DONTNEED) = 0
readlink("/proc/19289/exe", "/bin/dash", 4096) = 9
kill(19326, SIGKILL)                    = 0
close(47)                               = 0

ie. the socket exists and can be written to, but nothing answers on
the other end.

I checked the ~/.config/chromium/Singleton* files and they seem
alright: the process IDs match, and the socket points to the /tmp
directory in use by the chromium process. They all get cleaned up
properly when chrome stops and are re-created properly when it starts.

I *feel* this has started happening in the recent 53->55 upgrade,
which happened here on the 14th, but I can't be sure of that
correlation.

Any advice would be greatly appreciated, as this bug is annoying as
hell. :)

A.

-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable'), (1, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.7.0-0.bpo.1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages chromium depends on:
ii  libasound2           1.0.28-1
ii  libatk1.0-0          2.14.0-1
ii  libc6                2.19-18+deb8u7
ii  libcairo2            1.14.0-2.1+deb8u1
ii  libcups2             1.7.5-11+deb8u1
ii  libdbus-1-3          1.8.22-0+deb8u1
ii  libexpat1            2.1.0-6+deb8u3
ii  libfontconfig1       2.11.0-6.3+deb8u1
ii  libfreetype6         2.5.2-3+deb8u1
ii  libgcc1              1:4.9.2-10
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u5
ii  libglib2.0-0         2.42.1-1+b1
ii  libgtk2.0-0          2.24.25-3+deb8u1
ii  libjpeg62-turbo      1:1.3.1-12
ii  libnspr4             2:4.12-1+debu8u1
ii  libnss3              2:3.26-1+debu8u1
ii  libpango-1.0-0       1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpng12-0           1.2.50-2+deb8u2
ii  libstdc++6           4.9.2-10
ii  libwebp5             0.4.1-1.2+b2
ii  libwebpdemux1        0.4.1-1.2+b2
ii  libx11-6             2:1.6.2-3
ii  libx11-xcb1          2:1.6.2-3
ii  libxcb1              1.10-3+b1
ii  libxcomposite1       1:0.4.4-1
ii  libxcursor1          1:1.1.14-1+b1
ii  libxdamage1          1:1.1.4-2+b1
ii  libxext6             2:1.3.3-1
ii  libxfixes3           1:5.0.1-2+b2
ii  libxi6               2:1.7.4-1+b2
ii  libxml2              2.9.1+dfsg1-5+deb8u3
ii  libxrandr2           2:1.4.2-1+b1
ii  libxrender1          1:0.9.8-1+b1
ii  libxslt1.1           1.1.28-2+deb8u2
ii  libxss1              1:1.2.2-1
ii  libxtst6             2:1.2.2-1+b1
ii  x11-utils            7.7+2
ii  xdg-utils            1.1.0~rc1+git20111210-7.4

chromium recommends no packages.

Versions of packages chromium suggests:
ii  chromium-inspector  55.0.2883.75-1~deb8u1
ii  chromium-l10n       55.0.2883.75-1~deb8u1

-- no debconf information

Message #10 received at 848930@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: 848930@bugs.debian.org

Subject: Re: Bug#848930: Acknowledgement (kills fellow process if window doesn't have focus)

Date: Tue, 20 Dec 2016 21:04:03 -0500

for the record, I can also reproduce this in Gnome and MATE desktop
environments and with a fresh new user and/or profile.

so it seems this is not limited to xmonad: whenever chrome is in another
workspace, calling "chromium foo" will SIGKILL the existing instance.

a.
-- 
The history of any one part of the earth, like the life of a soldier,
consists of long periods of boredom and short periods of terror.
                       - British geologist Derek V. Ager

Message #15 received at 848930@bugs.debian.org (full text, mbox, reply):

From: Michael Gilbert <mgilbert@debian.org>

To: 848930@bugs.debian.org, 848930-submitter@bugs.debian.org

Subject: re: kills fellow process if window doesn't have focus

Date: Sat, 21 Jan 2017 19:27:30 -0500

control: tag -1 moreinfo, upstream

Did versions prior to the latest security update do this?  Is there an
upstream bug about it?  If not, please submit one and link back here.

Best wishes,
Mike

Message #27 received at 848930-quiet@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Michael Gilbert <mgilbert@debian.org>, 848930-quiet@bugs.debian.org

Subject: Re: Bug#848930: kills fellow process if window doesn't have focus

Date: Sun, 22 Jan 2017 14:26:43 -0500

On 2017-01-21 19:27:30, Michael Gilbert wrote:
> control: tag -1 moreinfo, upstream
>
> Did versions prior to the latest security update do this?  Is there an
> upstream bug about it?  If not, please submit one and link back here.

I haven't had the time to file a bug upstream yet.

This regression was introduced about a week or two before this bug was
filed. This is completely new: I wouldn't have endured such a behavior
very long.

In fact, this is one of the things that made me switch back to Firefox
now...

Thanks for the response...

-- 
Secrecy is the keystone to all tyranny. Not force, but secrecy and
censorship.
                       -  Robert A. Heinlein

Message #38 received at 848930-close@bugs.debian.org (full text, mbox, reply):

From: Michael Gilbert <mgilbert@debian.org>

To: 848930-close@bugs.debian.org

Subject: re: kills fellow process if window doesn't have focus

Date: Tue, 7 Nov 2017 21:54:01 -0500

This was fixed upstream in chromium 60.

Best wishes,
Mike

Send a report that this bug log contains spam.