Re: 4.85BETA2 posted to Nmap download page - please test

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

On Mon, Feb 2, 2009 at 5:25 PM, Brandon Enright <bmenrigh () ucsd edu> wrote:
> Okay so I *still* haven't been able to get the memory issue to come
> up again.

Was the script I gave you at all helpful? It's unfortunate the problem
hasn't resurfaced to make it useful: /

>  However, I just run into (for the first time) a infinite
> loop(?) issue with NSE.  Basically what happened is the Nmap process
> started using 100% of the CPU, NSE stopped making an progress reporting:

This is going to be very hard to track down in the current system. You
would want some form of stack trace during this time for each thread
running to see what function each thread is "waiting" in, be it a
mutex or socket. I don't believe gdb will be much help for you in this
regard because you want Lua stack traces and not C stack traces.

In the future, I would like to implement a system that has a timeout
for a thread holding an object but not resuming operation. That is, a
thread having a lock (not waiting) on a mutex which has not resumed
operation in ~30 seconds will be killed by NSE along with all threads
waiting on the mutex. By extension, a thread with an open socket that
has not run in ~30 seconds will also be killed and its resources
released.

Such a system would definitely require tighter resource tracking by
NSE. Debugging will become easier as a developer will be able to see
what mutexes a thread has acquired or what sockets it has open.

Cheers,

-- 
-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