Date: Wed, 27 Oct 2004 23:20:34 GMT From: David Xu <davidxu@freebsd.org> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/72979: unkillable process(es) stuck in `STOP' state Message-ID: <200410272320.i9RNKY0U031543@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/72979; it has been noted by GNATS. From: David Xu <davidxu@freebsd.org> To: Ken Smith <kensmith@cse.Buffalo.EDU> Cc: Mikhail Teterin <mi+mx@aldan.algebra.com>, Michael Nottebrock <michaelnottebrock@gmx.net>, re@freebsd.org, davidxu@t2t2.com, davidxu@viatech.com.cn, freebsd-gnats-submit@freebsd.org Subject: Re: kern/72979: unkillable process(es) stuck in `STOP' state Date: Thu, 28 Oct 2004 07:19:57 +0800 Ken Smith wrote: >On Tue, Oct 26, 2004 at 12:07:47PM -0400, Mikhail Teterin wrote: > > >>=On Tue, Oct 26, 2004 at 07:11:54PM +0800, David Xu wrote: >>=That looks both promising (given symptoms) and low-risk. >>= >>=Mikhail et. al., will you have any problems testing that? >> >>This problem was not easy to reproduce to begin with :-( >> >>I don't even know, how it can be positively claimed gone. Shall we merge >>David's fix into RELENG_5 and hope for the best? >> >> -mi >> >> > >Has anyone had time to test David's patch? If yes have you had >any problems since? > >I should know later today if the other person who had been reporting >problems has had them stop. He reported last night he was still able >to reproduce the problem but he hasn't had any "luck" doing it today. > >David, my only real question I guess is whether perhaps P_STOPPED_SINGLE >should be added to the flags that are being turned off by your patch. >If I'm following the code right what had made P_STOPPED_TRACE special >was it's one of the three signals lumped into P_STOPPED and the code >in do_tdsignal() looks for that, as well as I'm sure the schedulers... > > > P_STOPPED_SINGLE needn't be removed here, in fact, the flag should already be turned off at this point, if the flag is still there, then there must be a bug, thread_single(SINGLE_EXIT) should turn it off if it returns or thread will exit in the function. P_STOPPED_TRACE is cleared by debugger via PT_DETACH in sys_process.c, but if debugger dies without chance to call ptrace(PT_DETACH), then exit1() must clear it. David Xu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410272320.i9RNKY0U031543>