From owner-freebsd-stable@FreeBSD.ORG Thu Jan 14 09:10:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00D79106566B for ; Thu, 14 Jan 2010 09:10:38 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay006.isp.belgacom.be (mailrelay006.isp.belgacom.be [195.238.6.172]) by mx1.freebsd.org (Postfix) with ESMTP id 5C4048FC08 for ; Thu, 14 Jan 2010 09:10:37 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAP1mTktQyA8k/2dsb2JhbACBRdULhDAE Received: from 36.15-200-80.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([80.200.15.36]) by relay.skynet.be with ESMTP; 14 Jan 2010 09:41:48 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.3/8.14.3) with ESMTP id o0E8fljs001848; Thu, 14 Jan 2010 09:41:47 +0100 (CET) (envelope-from tijl@coosemans.org) From: Tijl Coosemans To: freebsd-stable@freebsd.org Date: Thu, 14 Jan 2010 09:41:45 +0100 User-Agent: KMail/1.9.10 References: <4B4D0293.3040704@rogers.com> <4B4DC490.5070001@rogers.com> <20100113143649.GS62907@deviant.kiev.zoral.com.ua> In-Reply-To: <20100113143649.GS62907@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201001140941.46748.tijl@coosemans.org> Cc: Kostik Belousov , Gardner Bell Subject: Re: process in STOP state X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 09:10:38 -0000 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 and then procstat -k 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.