process in STOP state
Tijl Coosemans
tijl at coosemans.org
Thu Jan 14 09:10:38 UTC 2010
On Wednesday 13 January 2010 15:36:49 Kostik Belousov wrote:
> 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:
>>>> 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.
Wine uses ptrace(2) sometimes. The SIGSTOP could have come from that.
I recently submitted http://www.freebsd.org/cgi/query-pr.cgi?pr=142757
describing a problem with ptrace and signals, so you might want to give
the kernel patch a try.
More information about the freebsd-stable
mailing list