Tijl Coosemans wrote:
On Friday 15 January 2010 02:31:22 David Xu wrote:
Tijl Coosemans wrote:
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.
The problem in your patch is that ksi pointer can not be hold across
thread sleeping, because once the process is resumed, there is no
guarantee that the thread will run first, once the signal came from
process's signal queue, other threads can remove the signal, and here
your sigqueue_take(ksi) is dangerous code.
If other threads can run before the current thread then there's a
second problem next to the one in the PR (current thread deletes
signal that shouldn't be deleted). Then those other threads can see
that the SIGSTOP bit (or another signal) is still set and stop the
process a second time. This might be what happens in the OP's case.
So, the signal has to be cleared before suspending the process, but
then other threads can still deliver other signals which might change
delivery order and I don't see any way around that besides introducing
a per process signal lock that is also kept while the process is
stopped. Comments?
I don't have an idea now, we ever delivered signal to thread's queue,
though it may lose signal if thread exits, but it does not have the problem
you have described here, we may need to rethink how to fix the signal-lost
problem but still deliver signal to thread's queue, just an idea.
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
