process in STOP state
Kostik Belousov
kostikbel at gmail.com
Wed Jan 13 14:36:55 UTC 2010
On Wed, Jan 13, 2010 at 08:03:12AM -0500, Gardner Bell wrote:
> Kostik Belousov wrote:
> >On Tue, Jan 12, 2010 at 06:15:31PM -0500, Gardner Bell wrote:
> >>Hello,
> >>
> >>Just updated my 8.0-STABLE desktop to r202128 the other day and can no
> >>longer run certain windows executables through wine without them almost
> >>immediately entering the STOP state and using 100% CPU for a short
> >>period of time. Has anyone else ran into a similar issue lately?
> >>
> >>I'm able to get the program to continue as normal by attaching the pid
> >>trough gdb, but would for obvious reasons prefer not to do that. Any
> >>help trying to find the underlying cause would be appreciated as this
> >>has not been a problem with revisions previous to r202128.
> >
> >You can check whether the process is multithreaded (most likely, it is),
> >and, if so, what is the state of different threads. procstat -t <pid>
> >and then procstat -k <pid> would probably give some information for
> >the start.
>
> Here's the output from procstat -k and -t. I've compiled my kernel with
> KDB and DDB support if there is anything needed from that.
>
> PID TID COMM TDNAME CPU PRI STATE WCHAN
> 44900 100162 wine initial thread 1 160 stop -
> 44900 100178 wine - 1 131 stop -
> 44900 100179 wine - 1 140 stop -
> 44900 100180 wine - 0 160 stop piperd
> 44900 100182 wine - 1 160 stop select
> 44900 100183 wine - 0 160 stop -
> 44900 100184 wine - 0 160 stop -
> 44900 100185 wine - 1 160 stop -
> 44900 100186 wine - 0 160 stop -
> 44900 100190 wine - 0 160 stop -
> 44900 100191 wine - 0 160 stop piperd
> 44900 100192 wine - 1 160 stop -
> 44900 100194 wine - 0 160 stop -
> 44900 100195 wine - 0 141 stop piperd
> 44900 100200 wine - 1 160 stop -
> 44900 100201 wine - 1 160 stop -
> 44900 100202 wine - 0 160 stop piperd
> 44900 100203 wine - 1 160 stop piperd
> 44900 100204 wine - 1 160 stop piperd
> 44900 100205 wine - 0 160 stop -
> 44900 100206 wine - 0 160 stop -
>
> %procstat -k 44900
> PID TID COMM TDNAME KSTACK
>
> 44900 100162 wine initial thread mi_switch
> thread_suspend_check as
> t doreti_ast
> 44900 100178 wine - mi_switch sleepq_switch
> sleepq_ca
> tch_signals sleepq_timedwait_sig
> _cv_timedwait_sig seltdwait kern_select select
>
> syscall Xint0x80_syscall
> 44900 100179 wine - mi_switch sleepq_switch
> sleepq_ca
> tch_signals sleepq_timedwait_sig
> _cv_timedwait_sig seltdwait kern_select select
>
> syscall Xint0x80_syscall
> 44900 100180 wine - mi_switch sleepq_switch
> sleepq_ca
> tch_signals sleepq_wait_sig
> _sleep pipe_read dofileread kern_readv read syscall
>
> Xint0x80_syscall
> 44900 100182 wine - mi_switch sleepq_switch
> sleepq_ca
> tch_signals sleepq_wait_sig
> _cv_wait_sig seltdwait poll syscall Xint0x80_syscall
>
>
> 44900 100183 wine - mi_switch sleepq_switch
> sleepq_ca
> tch_signals sleepq_timedwait_sig
> _cv_timedwait_sig seltdwait poll syscall Xint0x
>
> 80_syscall
> 44900 100184 wine - mi_switch sleepq_switch
> sleepq_ca
> tch_signals sleepq_timedwait_sig
> _cv_timedwait_sig seltdwait kern_select select
>
> syscall Xint0x80_syscall
> 44900 100185 wine - mi_switch sleepq_switch
> sleepq_ca
> tch_signals sleepq_timedwait_sig
> _cv_timedwait_sig seltdwait kern_select select
>
> syscall Xint0x80_syscall
> 44900 100186 wine - mi_switch sleepq_switch
> sleepq_ca
> tch_signals sleepq_timedwait_sig
> _cv_timedwait_sig seltdwait kern_select select
>
> syscall Xint0x80_syscall
> 44900 100190 wine - mi_switch sleepq_switch
> sleepq_ca
> tch_signals sleepq_timedwait_sig
> _cv_timedwait_sig seltdwait kern_select select
>
> syscall Xint0x80_syscall
> 44900 100191 wine - mi_switch sleepq_switch
> sleepq_ca
> tch_signals sleepq_wait_sig
> _sleep pipe_read dofileread kern_readv read syscall
>
> Xint0x80_syscall
> 44900 100192 wine - mi_switch sleepq_switch
> sleepq_ca
> tch_signals sleepq_wait_sig
> _sleep pipe_read dofileread kern_readv read syscall
>
> Xint0x80_syscall
> 44900 100194 wine - mi_switch sleepq_switch
> sleepq_ca
> tch_signals sleepq_wait_sig
> _sleep pipe_read dofileread kern_readv read syscall
>
> Xint0x80_syscall
> 44900 100195 wine - mi_switch sleepq_switch
> sleepq_ca
> tch_signals sleepq_wait_sig
> _sleep pipe_read dofileread kern_readv read syscall
>
> Xint0x80_syscall
> 44900 100200 wine - mi_switch sleepq_switch
> sleepq_ca
> tch_signals sleepq_timedwait_sig
> _sleep kern_kevent kevent syscall Xint0x80_sysc
>
> all
> 44900 100201 wine - mi_switch sleepq_switch
> sleepq_ca
> tch_signals sleepq_timedwait_sig
> _sleep kern_kevent kevent syscall Xint0x80_sysc
>
> all
> 44900 100202 wine - mi_switch sleepq_switch
> sleepq_ca
> tch_signals sleepq_wait_sig
> _sleep pipe_read dofileread kern_readv read syscall
>
> Xint0x80_syscall
> 44900 100203 wine - mi_switch sleepq_switch
> sleepq_ca
> tch_signals sleepq_wait_sig
> _sleep pipe_read dofileread kern_readv read syscall
>
> Xint0x80_syscall
> 44900 100204 wine - mi_switch sleepq_switch
> sleepq_ca
> tch_signals sleepq_wait_sig
> _sleep pipe_read dofileread kern_readv read syscall
>
> Xint0x80_syscall
> 44900 100205 wine - mi_switch sleepq_switch
> sleepq_ca
> tch_signals sleepq_timedwait_sig
> _sleep kern_kevent kevent syscall Xint0x80_sysc
>
> all
> 44900 100206 wine - mi_switch
> thread_suspend_switch c
> ursig ast doreti_ast
>
Besides weird formatting of procstat -k output, I do not see anything
wrong in the state of the process. It got SIGSTOP, I am sure. Attaching
gdb helps because debugger gets signal reports instead of target process
getting the signal actions on signal delivery.
The only question is why the process gets SIGSTOP at all.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100113/b1f03a43/attachment.pgp
More information about the freebsd-stable
mailing list