Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Dec 2016 17:28:09 -0600
From:      Eric Badger <eric@badgerio.us>
To:        freebsd-current@freebsd.org
Cc:        sgk@troutmask.apl.washington.edu
Subject:   Re: unkillable firefox
Message-ID:  <989b8638-e440-258a-5e61-bd1f2a177ef5@badgerio.us>
In-Reply-To: <20161220212920.GA69662@troutmask.apl.washington.edu>
References:  <20161220212920.GA69662@troutmask.apl.washington.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On 12/20/2016 15:29, Steve Kargl wrote:
> Anyone know how to kill firefox?
> 
> last pid: 69652;  load averages:  0.49,  0.27,  0.24      up 1+02:40:06  13:16:02
> 126 processes: 1 running, 121 sleeping, 4 stopped
> CPU:  0.8% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> Mem: 2049M Active, 3739M Inact, 496M Laundry, 1365M Wired, 783M Buf, 239M Free
> Swap: 16G Total, 1772K Used, 16G Free
> 
>   PID USERNAME   PRI NICE SIZE    RES STATE   C   TIME    WCPU COMMAND
> 63902 kargl      40   0  3157M  2302M STOP    1  10:50   0.00% firefox{firefox}
> 63902 kargl     -16   0  3157M  2302M STOP    2   5:46   0.00% firefox{Composit
> 16874 kargl      40   0   740M   330M STOP    1   0:07   0.00% firefox{firefox}
> 16874 kargl     -16   0   740M   330M STOP    1   0:00   0.00% firefox{Composit
> 
> It seems that firefox is wedged in the thread firefox{Compositor},
> and slowly eating up memory.  This is on an amd64 system at
> r310125 and latest firefox from ports.  procstat suggests that its
> stuck in a vm sleep queue.
> 
> % procstat -k 63902
>   PID    TID COMM       TDNAME       KSTACK                       
> 63902 100504 firefox    -            mi_switch thread_suspend_switch
>                                      thread_single exit1 sigexit postsig ast
>                                      Xfast_syscall 
> 63902 101494 firefox    Compositor   mi_switch sleepq_wait _sleep 
>                                      vm_page_busy_sleep vm_page_sleep_if_busy
>                                      vm_fault_hold vm_fault trap_pfault trap
>                                      calltrap 
> 

Do you have output of procstat -k for all threads? I'd guess one thread
is busy dumping core.

Eric



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?989b8638-e440-258a-5e61-bd1f2a177ef5>