process in STOP state

[Tijl Coosemans]

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?