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.
pgpspboPugaUc.pgp
Description: PGP signature
