How break deadlock?

I’ve trying to experiment using debugger to break possible deadlock.
Objective is to let the system continue when there is a keyborad and mouse
freeze, but we could break into debugger. This is one thing I was bumped
into two many times.

After I break in, I can look at the locks ( !locks ), finds that two or
three locks are held, I can look at the resource. Sometime I can find out
that it is on an event, and I could find if it is signalled or not. If I
change it from signalled to non-signalled or vice versa using debugger, and
switch threads to kick start each one ( out of total, say 5 thd), it does
not seem to kick start.

Questions -

  1. Is it possible to break any deadlocks this way?
  2. When could be a situation (perhaps always !) when this technique would
    not work?. And what to conclude from that situation? Is it the schedular
    path is also locked? Blah, blah …

Thanks
-pro

Prokash Sinha wrote:

I’ve trying to experiment using debugger to break possible deadlock.
Objective is to let the system continue when there is a keyborad and
mouse freeze, but we could break into debugger. This is one thing I
was bumped into two many times.

After I break in, I can look at the locks ( !locks ), finds that two
or three locks are held, I can look at the resource. Sometime I can
find out that it is on an event, and I could find if it is signalled
or not. If I change it from signalled to non-signalled or vice versa
using debugger, and switch threads to kick start each one ( out of
total, say 5 thd), it does not seem to kick start.

Questions -

  1. Is it possible to break any deadlocks this way?

That depends on what you mean. You may be able to break a deadlock, but
that does not mean your system will continue to operate. A deadlock is
a symptom of a larger problem, not a cause. You don’t have any idea
what those events are protecting. By breaking a lock, you may be
trashing some critical resource needed by a driver.

  1. When could be a situation (perhaps always !) when this technique
    would not work?

What you’re asking here is, in a way, a restatement of Alan Turing’s
unsolvable stopping problem.

There is no way to know when it will work and when it won’t. If the
event wasn’t needed, it wouldn’t be there. The fact that a thread is
blocked means that it isn’t supposed to run. You simply do not have
enough information to know if it is safe to continue.

And what to conclude from that situation? Is it the schedular path is
also locked?

Who knows? Perhaps some piece of hardware is broken.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Tim,

I would not go that far ( Alan Turing’s halting problem :). Also I
understand that there is/are deep problems there, that needs to be solved
before I call the day(debugging). Sure the root cause could be in so many
places ( And my role here is - “Someone elses problem is my paycheck …”).
I really don’t expect it to solve anything. Its just I’m dependent on the
workings of some other code(s).

The deadlocks comes under few flavors. Mostly coming from service thread(s).
Sometime ERESOURCE other time EVENTS. My sugery depends on so many things (
bood pressure, bood sugar, cholestorol, good appartus, etc., etc of the
sofware/hw components ), so I was thinking what if I give a bit of a push to
the chest, to see if the heart can continue a bit …, and perhaps gets to
another choke point.

Many times, just by perturbing memory locations, redirecting jmp location
etc., I was able to narrow down the scope of the problematic domain. And I
was hoping, something similar could be achieved here.

Oh well, …

-pro

On 2/13/07, Tim Roberts wrote:
>
> Prokash Sinha wrote:
> > I’ve trying to experiment using debugger to break possible deadlock.
> > Objective is to let the system continue when there is a keyborad and
> > mouse freeze, but we could break into debugger. This is one thing I
> > was bumped into two many times.
> >
> > After I break in, I can look at the locks ( !locks ), finds that two
> > or three locks are held, I can look at the resource. Sometime I can
> > find out that it is on an event, and I could find if it is signalled
> > or not. If I change it from signalled to non-signalled or vice versa
> > using debugger, and switch threads to kick start each one ( out of
> > total, say 5 thd), it does not seem to kick start.
> >
> > Questions -
> >
> > 1) Is it possible to break any deadlocks this way?
>
> That depends on what you mean. You may be able to break a deadlock, but
> that does not mean your system will continue to operate. A deadlock is
> a symptom of a larger problem, not a cause. You don’t have any idea
> what those events are protecting. By breaking a lock, you may be
> trashing some critical resource needed by a driver.
>
>
> > 2) When could be a situation (perhaps always !) when this technique
> > would not work?
>
> What you’re asking here is, in a way, a restatement of Alan Turing’s
> unsolvable stopping problem.
>
> There is no way to know when it will work and when it won’t. If the
> event wasn’t needed, it wouldn’t be there. The fact that a thread is
> blocked means that it isn’t supposed to run. You simply do not have
> enough information to know if it is safe to continue.
>
>
> > And what to conclude from that situation? Is it the schedular path is
> > also locked?
>
> Who knows? Perhaps some piece of hardware is broken.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> You are currently subscribed to windbg as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>