Killing processes from DDB

[Matt Burke]

On 08/30/12 09:12, Konstantin Belousov wrote:
> Stop state indicates that the process is stopped or being stopped. The later
> is your case. The process has one thread executing exit1() kernel function,
> which terminates the process. In the course of work, the function notifies
> all other threads of the exiting process that they shall terminate ASAP at
> the next safe point.

Thanks for the explanation - I thought stop state was just a mechanism for
processes to pause (as in ^Z from the shell) by being skipped by the
scheduler or something... Looking in /sys/kern I think I need to do a lot
of reading to correct what appear to be some bad assumptions I've picked up
over the years.


> The way to debug the issue is to break into ddb on console and get
> a backtrace for the spinning thread, then continue, then break again
> and get another backtrace. Do it several times, to see where the code
> spins.

Understood.


> It is impossible to even start guessing what is wrong, without seeing
> the backtrace.
> 
> Still, recompiling VB could be good idea, since VB kernel module uses
> non-stable KPI and KBI, thus what you see might be just build issue.

Indeed, however I find Bad Things happening are a great excuse to learn
more about the system's innards ;)



-- 


The information contained in this message is confidential and intended for the addressee only. If you have received this message in error, or there are any problems with its content, please contact the sender. 

iCritical is a trading name of Critical Software Ltd. Registered in England: 04909220.
Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH.

This message has been scanned for security threats by iCritical. www.icritical.com