Re: Possible script deadlock while testing in nse-lua-merge

[Patrick Donnelly <batrick () batbytes com>]

HI David,

On Tue, Mar 24, 2009 at 10:16 PM, David Fifield <david () bamsoftware com> wrote:
> On Tue, Mar 24, 2009 at 08:50:35PM -0600, Patrick Donnelly wrote:
> > On Tue, Mar 24, 2009 at 7:10 PM, David Fifield <david () bamsoftware com> wrote:
> > > Can you explain more fully the nature of this problem?
> >
> > It could be a variety of problems that prevent scripts from ever
> > obtaining a socket connection. I think the most probable is that some
> > script is holding on to references of a socket even after finishing
> > execution.
>
> What is holding the reference to the socket? Is the script thread
> garbage collected after it terminates? Maybe we have to add a call to
> the garbage collector in the Lua snippet in luaopen_nsock?

For NSE in C++:
  We are holding a reference to the thread via a LUA_REGISTRY index.
The thread will then hold references to all functions on the stack
which in turn hold references to their respective environment tables
(where the action function resides). Once we delete the reference in
the registry, Lua will collect the thread.

For NSE in Lua:
  We keep a reference to each thread in a class (table) as you can see
in nse_main.lua. All references held by NSE to each thread are deleted
in between host groups.

However...

For both of these situations, a thread may save a reference to itself
in many different ways preventing its eventual garbage collection.
Essentially, all that is required is placing the thread in a
persistent location, including, the global enviornment (_G), the nmap
(or any library) table, or the registry (nmap.registry). Of course the
users also have access to the debug library which makes ensuring a
thread and its resources being collected extremely difficult. Finally,
the script does not _need_ to save a reference of itself, it can just
save any of the resources we would want collected (sockets in
particular).

For these reasons, calling the garbage collector (in the nsock
library) doesn't help. The garbage collector is always running anyway.
We need a more sophisticated technique of enforcing parallelism. I
think this warrants a lot of discussion on the list but I fear too
many people are unfamiliar with the challenges.

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