Date: Thu, 7 Mar 2002 14:52:36 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: arch@freebsd.org Cc: phk@freebsd.org Subject: Re: Contemplating THIS change to signals. (fwd) Message-ID: <Pine.BSF.4.21.0203071445010.37321-100000@InterJet.elischer.org>
next in thread | raw e-mail | index | archive | help
oh yes, here is one other way that you can tell the difference between the two cases.. I take this to be a bug :-) Peter's fix a a bandaid to take into account that the STOP type signals are being handled in places other than userret. ---------- Forwarded message ---------- Date: Thu, 07 Mar 2002 11:30:35 +0000 From: Peter Edwards <peter.edwards@openet-telecom.com> To: Julian Elischer <julian@elischer.org> Cc: FreeBSD current users <current@freebsd.org>, Mckusick@mckusick.com Subject: Re: Contemplating THIS change to signals. I mentioned something similar for a different reason. Go look at the last part of the following message in the recent -hackers archives: > Subject: ptrace bug? > MessageId: <3C712885.A0A91264@openet-telecom.com> (this was for -stable, BTW) Having the suspend for the ptrace()ing parent done in issignal is a pain when issignal is called multiple times by the debuggee before getting back to userland. The debugger sees wait() return more than once reporting the same signal depending on where the victim process was when it stopped, and the code path back to userland. It's particularly noticable when the ptrace(PT_CONTINUE) tries to continue the process with a signal, and the signal arrives back at the debugger. The debugger has no idea wheather it sees the signal because it tried to send it, or the same signal raised for some other reason. The results of this can be seen in GDB frequently when you use the "signal" command. I suggested moving the ptrace handling to postsig(), but anything along the lines of what you are mentioning seems like an improvement to me, and I'm sure you're much more likely to know what you're doing :-) I only delved in here briefly to try and work out some of the non-obvious behaviour of ptrace(). Oh, and while your mucking with issignal(), any chance of looking at the bug raised (and the patch) in the start of that message, and in PR kern/35175? :-) -- Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0203071445010.37321-100000>