/usr/lib/firefox-4.0/plugin-container hangs upon Firefox exit, which prevents computer shutdown from GNOME

Bug #764621 reported by Martin-Éric Racine
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
firefox (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: firefox

Every time I exit Firefox before rebooting this host running a classic GNOME session, it hangs there, effectivel preventing the reboot from taking place unless Firefox is first force-killed. The cause seems to be that Firefox's plugin container has a dozen of Gnash sub-processes that won't terminate.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: firefox 4.0+nobinonly-0ubuntu2
ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2
Uname: Linux 2.6.38-8-generic i686
Architecture: i386
Date: Mon Apr 18 16:21:00 2011
FirefoxPackages:
 firefox 4.0+nobinonly-0ubuntu2
 flashplugin-installer N/A
 adobe-flashplugin N/A
 icedtea-plugin N/A
ProcEnviron:
 LANGUAGE=fi_FI:fi_FI.UTF-8:fi
 PATH=(custom, user)
 LANG=fi_FI.UTF-8
 SHELL=/bin/bash
SourcePackage: firefox
UpgradeStatus: Upgraded to natty on 2009-09-14 (581 days ago)

Revision history for this message
Martin-Éric Racine (q-funk) wrote :
summary: - /usr/lib/firefox-4.0/plugin-container hangs upon Firefo exit, which
+ /usr/lib/firefox-4.0/plugin-container hangs upon Firefox exit, which
prevents computer shutdown from GNOME
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in firefox (Ubuntu):
status: New → Confirmed
Revision history for this message
markusj (markusj) wrote :

Same here on Ubuntu 10.10 with Firefox 3.6.23. I think this issue appeared after one of the last adobe-flashplugin updates.

Revision history for this message
Igor Wojnicki (wojnicki) wrote :

Same here. I've got a feeling that the bug emerged after the last flash plugin update. The plugin container can be terminated via kill though.

Revision history for this message
Igor Wojnicki (wojnicki) wrote :

It's still there even after upgrading to ff 3.6.24

Revision history for this message
markusj (markusj) wrote : Re: [Bug 764621] Re: /usr/lib/firefox-4.0/plugin-container hangs upon Firefox exit, which prevents computer shutdown from GNOME

Am 11.11.2011 12:58, schrieb Igor Wojnicki:
> Same here. I've got a feeling that the bug emerged after the last flash
> plugin update. The plugin container can be terminated via kill though.

Not always, sometimes (but very infrequent) it's in state [defunc] and
only killing firefox-bin itself works.

Revision history for this message
Michael Mess (michael-michaelmess) wrote :

I am suffering from the same problem.

Today again, when I logged out from the computer, it told me about the hanging firefox-bin process, but I just logged out anyway.

This left two processes bumming around.

18727 ? Sl 0:25 /usr/lib/firefox-3.6.24/firefox-bin
18768 ? Tl 0:04 /usr/lib/firefox-3.6.24/plugin-container /usr/lib/adobe-flashplugin/libflashplayer.so 18727 plugin true

I have tried to strace -p 18768, but with no success, even as root:

root@quad:~# strace -p 18768
attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted

I also tried to send SIGCONT ( kill -18 ) to 18768, but with no success.

It seems that the firefox-bin process is waiting for the plugin-container, which is a stopped process, thus waiting forever.

michael@quad:~$ strace -p 18727
Process 18727 attached - interrupt to quit
futex(0xa2cffbd8, FUTEX_WAIT, 18767, NULL

When exiting firefox there should be a timeout waiting for plugins and if the plugin-container or any other spawned process is detected in a stopped state, it should be just killed with SIGKILL.

Revision history for this message
Michael Mess (michael-michaelmess) wrote :

Further analysis:

michael@quad:~$ pstree -p 18727
firefox-bin(18727)─┬─plugin-containe(18768)───{plugin-contain}(18769)
                   ├─{firefox-bin}(18742)
                   ├─{firefox-bin}(18743)
                   ├─{firefox-bin}(18767)
                   └─{firefox-bin}(18782)

ps -xms shows these infos:

 1000 18727 0000000000000000 - - - - ? 0:25 /usr/lib/firefox-3.6.24/firefox-bin
 1000 - 0000000000000000 0000000000000000 0000000000001000 0000000180004087 Sl - 0:23 -
 1000 - 0000000000000000 0000000000000000 0000000000001000 0000000180004087 Sl - 0:00 -
 1000 - 0000000000000000 0000000000000000 0000000000001000 0000000180004087 Sl - 0:00 -
 1000 - 0000000000000000 0000000000000000 0000000000001000 0000000180004087 Sl - 0:00 -
 1000 - 0000000000000000 fffffffe7ffbfeff 0000000000001000 0000000180004087 Sl - 0:00 -
 1000 18768 0000000000000000 - - - - ? 0:04 /usr/lib/firefox-3.6.24/plugin-container /usr/lib/adobe-flashplugin/libflashplayer.so 18727 plugin true
 1000 - 0000000000000000 0000000000000000 0000000000001000 00000001800a04e8 Tl - 0:00 -
 1000 - 0000000000000000 00000000000004e8 0000000000001000 00000001800a04e8 Sl - 0:02 -

Revision history for this message
Michael Mess (michael-michaelmess) wrote :

The output of ps xHwl shows that the process seems to be ptraced.

0 1000 18727 1 20 0 252264 60284 futex_ Sl ? 0:23 /usr/lib/firefox-3.6.24/firefox-bin
1 1000 18727 1 20 0 252264 60284 futex_ Sl ? 0:00 /usr/lib/firefox-3.6.24/firefox-bin
1 1000 18727 1 20 0 252264 60284 futex_ Sl ? 0:00 /usr/lib/firefox-3.6.24/firefox-bin
1 1000 18727 1 20 0 252264 60284 wait Sl ? 0:00 /usr/lib/firefox-3.6.24/firefox-bin
1 1000 18727 1 20 0 252264 60284 poll_s Sl ? 0:00 /usr/lib/firefox-3.6.24/firefox-bin
0 1000 18768 18727 20 0 104156 18380 ptrace Tl ? 0:00 /usr/lib/firefox-3.6.24/plugin-container /usr/lib/adobe-flashplugin/libflashplayer.so 18727 plugin true
1 1000 18768 18727 20 0 104156 18380 unix_s Sl ? 0:02 /usr/lib/firefox-3.6.24/plugin-container /usr/lib/adobe-flashplugin/libflashplayer.so 18727 plugin true

This would explain, why strace could not connect. From the documentation of the ptrace system call:

"EPERM
    The specified process cannot be traced. This could be because the parent has insufficient privileges (the required capability is CAP_SYS_PTRACE); unprivileged processes cannot trace processes that they cannot send signals to or those running set-user-ID/set-group-ID programs, for obvious reasons. Alternatively, the process may already be being traced, or be init(8) (PID 1). "

Does firefox make use of the ptrace system call to control its subprocess?

Revision history for this message
Michael Mess (michael-michaelmess) wrote :

michael@quad:/proc/18768$ cat status
Name: plugin-containe
State: T (tracing stop)
Tgid: 18768
Pid: 18768
PPid: 18727
TracerPid: 18767
Uid: 1000 1000 1000 1000
Gid: 1000 1000 1000 1000
FDSize: 256
Groups: 4 20 24 25 29 30 44 46 107 109 115 129 135 139 1000
VmPeak: 132316 kB
VmSize: 104156 kB
VmLck: 0 kB
VmHWM: 40712 kB
VmRSS: 18380 kB
VmData: 44800 kB
VmStk: 88 kB
VmExe: 4 kB
VmLib: 54888 kB
VmPTE: 268 kB
Threads: 2
SigQ: 0/16382
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000001000
SigCgt: 00000001800a04e8
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: ffffffffffffffff
Cpus_allowed: f
Cpus_allowed_list: 0-3
Mems_allowed: 1
Mems_allowed_list: 0
voluntary_ctxt_switches: 4591
nonvoluntary_ctxt_switches: 5

michael@quad:/proc/18768$ cat stack
[<c015f939>] ptrace_stop+0x99/0x160
[<c0160244>] get_signal_to_deliver+0x1b4/0x3c0
[<c01030a3>] do_signal+0x73/0x170
[<c01031f5>] do_notify_resume+0x55/0x80
[<c01034c8>] work_notifysig+0x13/0x1b
[<ffffffff>] 0xffffffff

Revision history for this message
Michael Mess (michael-michaelmess) wrote :

I just straced the firefox-bin process:

michael@quad:~$ strace -p 18727
Process 18727 attached - interrupt to quit
futex(0xa2cffbd8, FUTEX_WAIT, 18767, NULL) = ? ERESTARTSYS (To be restarted)
--- SIGCHLD (Child exited) @ 0 (0) ---
futex(0xa2cffbd8, FUTEX_WAIT, 18767, NULL) = ? ERESTARTSYS (To be restarted)
--- SIGCHLD (Child exited) @ 0 (0) ---
futex(0xa2cffbd8, FUTEX_WAIT, 18767, NULL) = ? ERESTARTSYS (To be restarted)
--- SIGCHLD (Child exited) @ 0 (0) ---
futex(0xa2cffbd8, FUTEX_WAIT, 18767, NULL) = 0
munmap(0xb62fe000, 8392704) = 0
writev(14, [{"GIOP\1\2\1\5\0\0\0\0", 12}], 1) = -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
close(14) = 0
writev(12, [{"GIOP\1\2\1\5\0\0\0\0", 12}], 1) = -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
close(12) = 0
close(9) = 0
close(8) = 0
unlink("/tmp/orbit-michael/linc-4927-0-3d737aaabe747") = 0
close(13) = 0
close(86) = 0
exit_group(0) = ?
Process 18727 detached

Then I sent SIGCHILD to it some times with no success, because I remembered that SIGCHILD was sometimes useful to reanimate a hanging Netscape process in the past.
When I killed the plugin-container subprocess (kill -9 18768), the firefox-bin process continued and terminated normally.

Revision history for this message
Michael Mess (michael-michaelmess) wrote :

Today I got the issue at work, but a little bit different:

This time the plugin container was a Zombie process, that means the plugin container process has already exited, but its parent process didn't care about it yet.
Thus this time killing the plugin-container process didn't help, because it was already dead.
Sending SIGCHLD to the parent process also didn't help.
Sending SIGTERM to the parent process removed the processes.

It seems that there are two different bugs, resulting in firefox-bin to hang:
 - One bug that freezes the plugin-container
 - One bug that lets firefox-bin hang, even after the plugin-container process has exited.

13865 ? Sl 3:58 /usr/lib/firefox-3.6.24/firefox-bin
13901 ? Zl 0:25 \_ [plugin-containe] <defunct>

michael@musca:~ $ pstree -p 13865
firefox-bin(13865)─┬─plugin-containe(13901)───{plugin-contain}(13902)
                   ├─{firefox-bin}(13874)
                   ├─{firefox-bin}(13876)
                   ├─{firefox-bin}(13877)
                   ├─{firefox-bin}(13900)
                   └─{firefox-bin}(14545)

michael@musca:/proc/13865 $ cat stack
[<c0178fa5>] futex_wait_queue_me+0xa5/0xd0
[<c017a278>] futex_wait+0x1a8/0x2c0
[<c017bab6>] do_futex+0xe6/0x1f0
[<c017bc32>] sys_futex+0x72/0x120
[<c01033ec>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff

futex(0xb74a2bd8, FUTEX_WAIT, 13874, NULL) = ? ERESTARTSYS (To be restarted)
--- SIGCHLD (Child exited) @ 0 (0) ---
send(17, "a", 1, 0) = -1 EAGAIN (Resource temporarily unavailable)
sigreturn() = ? (mask now [])
futex(0xb74a2bd8, FUTEX_WAIT, 13874, NULL <unfinished ...>
+++ killed by SIGTERM +++

At home and at work I have Firefox 3.6.24:

Package: firefox
Version: 3.6.24+build2+nobinonly-0ubuntu0.10.04.1

Revision history for this message
Michael Mess (michael-michaelmess) wrote :
Download full text (4.6 KiB)

Today again: The plugin-container was stopped again and firefox was waiting for it forever...
... until I attached strace to each process and killed the plugin-container process with SIGKILL,
letting the other processes resume and exit normally.
The resulting strace logs may give a hint, where firefox is waiting for the stopped process.

 7284 ? Sl 0:28 /usr/lib/firefox-3.6.24/firefox-bin
 7320 ? Tl 0:00 \_ /usr/lib/firefox-3.6.24/plugin-container /usr/lib

michael@quad:~$ pstree -p 7284
firefox-bin(7284)─┬─plugin-containe(7320)───{plugin-contain}(7321)
                  ├─{firefox-bin}(7294)
                  ├─{firefox-bin}(7295)
                  ├─{firefox-bin}(7316)
                  └─{firefox-bin}(7319)

michael@quad:~$ kill -9 7320

michael@quad:~$ strace -p 7284
Process 7284 attached - interrupt to quit
futex(0x9e6fabd8, FUTEX_WAIT, 7319, NULL) = 0
munmap(0xb36ff000, 8392704) = 0
writev(14, [{"GIOP\1\2\1\5\0\0\0\0", 12}], 1) = 12
close(14) = 0
writev(12, [{"GIOP\1\2\1\5\0\0\0\0", 12}], 1) = 12
close(12) = 0
close(9) = 0
close(8) = 0
unlink("/tmp/orbit-michael/linc-1c74-0-506155318a2b") = 0
close(13) = 0
close(73) = 0
exit_group(0) = ?
Process 7284 detached

michael@quad:~$ strace -p 7319
Process 7319 attached - interrupt to quit
waitpid(7320, NULL, __WALL) = ? ERESTARTSYS (To be restarted)
--- SIGCHLD (Child exited) @ 0 (0) ---
waitpid(7320, NULL, __WALL) = 7320
--- SIGCHLD (Child exited) @ 0 (0) ---
ptrace(PTRACE_ATTACH, 7321, 0, 0) = -1 ESRCH (No such process)
ftruncate(34, 0) = 0
close(34) = 0
ptrace(PTRACE_DETACH, 7320, 0, SIG_0) = -1 ESRCH (No such process)
ptrace(PTRACE_DETACH, 7321, 0, SIG_0) = -1 ESRCH (No such process)
munmap(0xb4012000, 4096) = 0
munmap(0xb4013000, 4096) = 0
munmap(0xb4400000, 4096) = 0
munmap(0xb4401000, 4096) = 0
munmap(0xb4402000, 4096) = 0
munmap(0xb4403000, 4096) = 0
munmap(0xb4404000, 4096) = 0
munmap(0xb4405000, 4096) = 0
munmap(0xb4406000, 4096) = 0
munmap(0xb4407000, 4096) = 0
munmap(0xb4408000, 4096) = 0
munmap(0xb4409000, 4096) = 0
munmap(0xb440a000, 4096) = 0
munmap(0xb4f00000, 4096) = 0
munmap(0xb4f01000, 4096) = 0
munmap(0xb4f02000, 4096) = 0
munmap(0xb4f03000, 4096) = 0
munmap(0xb4f04000, 4096) = 0
munmap(0xb4f05000, 4096) = 0
munmap(0xb4f06000, 4096) = 0
munmap(0xb5200000, 4096) = 0
munmap(0xb5201000, 4096) = 0
munmap(0xb5202000, 4096) = 0
munmap(0xb7400000, 4096) = 0
munmap(0xb7401000, 4096) = 0
munmap(0xb7700000, 4096) = 0
munmap(0xb7825000, 4096) = 0
close(27) ...

Read more...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.