From owner-freebsd-stable@FreeBSD.ORG Wed Jan 13 14:36:55 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 6D0E3106566C for ; Wed, 13 Jan 2010 14:36:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id B7A938FC0A for ; Wed, 13 Jan 2010 14:36:54 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o0DEanAi072309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Jan 2010 16:36:49 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id o0DEanqA086039; Wed, 13 Jan 2010 16:36:49 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id o0DEancO086038; Wed, 13 Jan 2010 16:36:49 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 13 Jan 2010 16:36:49 +0200 From: Kostik Belousov To: Gardner Bell Message-ID: <20100113143649.GS62907@deviant.kiev.zoral.com.ua> References: <4B4D0293.3040704@rogers.com> <20100113085014.GN62907@deviant.kiev.zoral.com.ua> <4B4DC490.5070001@rogers.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ctZH5Gqgrl5HoVnD" Content-Disposition: inline In-Reply-To: <4B4DC490.5070001@rogers.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org 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: Wed, 13 Jan 2010 14:36:55 -0000 --ctZH5Gqgrl5HoVnD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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= =20 > >>longer run certain windows executables through wine without them almost= =20 > >>immediately entering the STOP state and using 100% CPU for a short=20 > >>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= =20 > >>trough gdb, but would for obvious reasons prefer not to do that. Any= =20 > >>help trying to find the underlying cause would be appreciated as this= =20 > >>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. >=20 > Here's the output from procstat -k and -t. I've compiled my kernel with= =20 > KDB and DDB support if there is anything needed from that. >=20 > 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 - >=20 > %procstat -k 44900 > PID TID COMM TDNAME KSTACK=20 >=20 > 44900 100162 wine initial thread mi_switch=20 > thread_suspend_check as=20 > t doreti_ast > 44900 100178 wine - mi_switch sleepq_switch=20 > sleepq_ca=20 > tch_signals sleepq_timedwait_sig= =20 > _cv_timedwait_sig seltdwait kern_select select=20 >=20 > syscall Xint0x80_syscall > 44900 100179 wine - mi_switch sleepq_switch=20 > sleepq_ca=20 > tch_signals sleepq_timedwait_sig= =20 > _cv_timedwait_sig seltdwait kern_select select=20 >=20 > syscall Xint0x80_syscall > 44900 100180 wine - mi_switch sleepq_switch=20 > sleepq_ca=20 > tch_signals sleepq_wait_sig=20 > _sleep pipe_read dofileread kern_readv read syscall=20 >=20 > Xint0x80_syscall > 44900 100182 wine - mi_switch sleepq_switch=20 > sleepq_ca=20 > tch_signals sleepq_wait_sig=20 > _cv_wait_sig seltdwait poll syscall Xint0x80_syscall=20 >=20 >=20 > 44900 100183 wine - mi_switch sleepq_switch=20 > sleepq_ca=20 > tch_signals sleepq_timedwait_sig= =20 > _cv_timedwait_sig seltdwait poll syscall Xint0x=20 >=20 > 80_syscall > 44900 100184 wine - mi_switch sleepq_switch=20 > sleepq_ca=20 > tch_signals sleepq_timedwait_sig= =20 > _cv_timedwait_sig seltdwait kern_select select=20 >=20 > syscall Xint0x80_syscall > 44900 100185 wine - mi_switch sleepq_switch=20 > sleepq_ca=20 > tch_signals sleepq_timedwait_sig= =20 > _cv_timedwait_sig seltdwait kern_select select=20 >=20 > syscall Xint0x80_syscall > 44900 100186 wine - mi_switch sleepq_switch=20 > sleepq_ca=20 > tch_signals sleepq_timedwait_sig= =20 > _cv_timedwait_sig seltdwait kern_select select=20 >=20 > syscall Xint0x80_syscall > 44900 100190 wine - mi_switch sleepq_switch=20 > sleepq_ca=20 > tch_signals sleepq_timedwait_sig= =20 > _cv_timedwait_sig seltdwait kern_select select=20 >=20 > syscall Xint0x80_syscall > 44900 100191 wine - mi_switch sleepq_switch=20 > sleepq_ca=20 > tch_signals sleepq_wait_sig=20 > _sleep pipe_read dofileread kern_readv read syscall=20 >=20 > Xint0x80_syscall > 44900 100192 wine - mi_switch sleepq_switch=20 > sleepq_ca=20 > tch_signals sleepq_wait_sig=20 > _sleep pipe_read dofileread kern_readv read syscall=20 >=20 > Xint0x80_syscall > 44900 100194 wine - mi_switch sleepq_switch=20 > sleepq_ca=20 > tch_signals sleepq_wait_sig=20 > _sleep pipe_read dofileread kern_readv read syscall=20 >=20 > Xint0x80_syscall > 44900 100195 wine - mi_switch sleepq_switch=20 > sleepq_ca=20 > tch_signals sleepq_wait_sig=20 > _sleep pipe_read dofileread kern_readv read syscall=20 >=20 > Xint0x80_syscall > 44900 100200 wine - mi_switch sleepq_switch=20 > sleepq_ca=20 > tch_signals sleepq_timedwait_sig= =20 > _sleep kern_kevent kevent syscall Xint0x80_sysc=20 >=20 > all > 44900 100201 wine - mi_switch sleepq_switch=20 > sleepq_ca=20 > tch_signals sleepq_timedwait_sig= =20 > _sleep kern_kevent kevent syscall Xint0x80_sysc=20 >=20 > all > 44900 100202 wine - mi_switch sleepq_switch=20 > sleepq_ca=20 > tch_signals sleepq_wait_sig=20 > _sleep pipe_read dofileread kern_readv read syscall=20 >=20 > Xint0x80_syscall > 44900 100203 wine - mi_switch sleepq_switch=20 > sleepq_ca=20 > tch_signals sleepq_wait_sig=20 > _sleep pipe_read dofileread kern_readv read syscall=20 >=20 > Xint0x80_syscall > 44900 100204 wine - mi_switch sleepq_switch=20 > sleepq_ca=20 > tch_signals sleepq_wait_sig=20 > _sleep pipe_read dofileread kern_readv read syscall=20 >=20 > Xint0x80_syscall > 44900 100205 wine - mi_switch sleepq_switch=20 > sleepq_ca=20 > tch_signals sleepq_timedwait_sig= =20 > _sleep kern_kevent kevent syscall Xint0x80_sysc=20 >=20 > all > 44900 100206 wine - mi_switch=20 > thread_suspend_switch c=20 > ursig ast doreti_ast >=20 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. --ctZH5Gqgrl5HoVnD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktN2oAACgkQC3+MBN1Mb4gSaACeKu+9LoMQv1Uqr1JROLM9tGqi c/gAoLk5WySleR68HBn0wsoPCWUq72q/ =vB5F -----END PGP SIGNATURE----- --ctZH5Gqgrl5HoVnD--