Nmap Development mailing list archives
Re: [NSE] A Lua implementation of NSE--chance for deadlock
From: "Patrick Donnelly" <batrick.donnelly () gmail com>
Date: Tue, 20 Jan 2009 18:06:54 -0700
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
Current thread:
- [NSE] A Lua implementation of NSE Patrick Donnelly (Jan 06)
- Re: [NSE] A Lua implementation of NSE Brandon Enright (Jan 07)
- Re: [NSE] A Lua implementation of NSE David Fifield (Jan 15)
- Re: [NSE] A Lua implementation of NSE--detailed review David Fifield (Jan 16)
- Re: [NSE] A Lua implementation of NSE--detailed review Patrick Donnelly (Jan 17)
- Re: [NSE] A Lua implementation of NSE--detailed review Patrick Donnelly (Jan 17)
- Re: [NSE] A Lua implementation of NSE--detailed review David Fifield (Jan 18)
- Re: [NSE] A Lua implementation of NSE--detailed review Patrick Donnelly (Jan 20)
- Re: [NSE] A Lua implementation of NSE--detailed review Patrick Donnelly (Jan 17)
- Re: [NSE] A Lua implementation of NSE Ron (Jan 17)
- Re: [NSE] A Lua implementation of NSE--chance for deadlock David Fifield (Jan 18)
- Re: [NSE] A Lua implementation of NSE--chance for deadlock Patrick Donnelly (Jan 20)
- Re: [NSE] A Lua implementation of NSE Patrick Donnelly (Jan 20)
- Re: [NSE] A Lua implementation of NSE Fyodor (Jan 20)
- Re: [NSE] A Lua implementation of NSE--chance for deadlock David Fifield (Jan 18)