Re: [NSE] A Lua implementation of NSE--chance for deadlock

["Patrick Donnelly" <batrick.donnelly () gmail com>]

On Sun, Jan 18, 2009 at 10:50 PM, David Fifield <david () bamsoftware com> wrote:
> On Sat, Jan 17, 2009 at 10:09:57PM -0600, Ron wrote:
> > I've finally had time to read this posting, since I'm on vacation. I
> > just had a couple quick thoughts...
> >
> > > These are the following ways a thread may yield and whether its host
> > > will still be charged time.
> > > [...]
> > > o A thread blocked on a mutex or condition variable (see nse.condvar)
> > > will not be charged time.
> >
> > This may be fixed in other ways (such as your push/pop_handler)
> > function, but one of the things that saved a lot of trouble when me and
> > Brandon were testing was the fact that a thread that was stuck on a
> > mutex (that is, waiting on a mutex that would never be released) would
> > eventually time out, and the execution would end. Am I correct in
> > thinking that, if you pushed that change, deadlocked scripts would never
> > finish?
> >
> > I think it's good if there's some way for scripts stuck in a mutex to
> > get out, eventually, if there isn't one.
>
> I tested this by creating a script that locks the same mutex twice in a
> row (attached).

This actually will result in undefined behavior. A thread should never
lock the same mutex twice. But for our purposes it does demonstrate
the problem.

> With nmap trunk, as you described, host timeout saves
> the day:
>
> $ nmap --datadir=. --script=lock --host-timeout 5s localhost
> host-timeout is given in milliseconds, so you specified less than 15 seconds (5000ms). This is allowed but not 
> recommended.
>
> Starting Nmap 4.76 ( http://nmap.org ) at 2009-01-18 22:37 MST
> Skipping host localhost (127.0.0.1) due to host timeout
>
> Nmap done: 1 IP address (1 host up) scanned in 5.29 seconds
>
> But you are correct that the nse-lua branch locks up forever.
>
> When you're back from vacation, could you make short test scripts that
> simulate a deadlock caused by an error, and recover from it with an exit
> handler? It would be good to know if that is feasible.

This is an excellent (and intended) use for the cleanup handlers.
Fixing deadlock could be very complicated, I wonder if it is worth the
cost in complexity?


-- 
-Patrick Donnelly

"One of the lessons of history is that nothing is often a good thing
to do and always a clever thing to say."

-Will Durant

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org