process in STOP state

David Xu davidxu at freebsd.org
Sun Jan 17 01:48:30 UTC 2010


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.




More information about the freebsd-stable mailing list