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

[David Fifield <david () bamsoftware com>]

On Tue, Mar 24, 2009 at 05:29:13PM -0600, Patrick Donnelly wrote:
> [Forwarding this to the list 5 days later because I replied to the wrong sender]
> On Thu, Mar 19, 2009 at 12:55 AM, Brandon Enright <bmenrigh () ucsd edu> wrote:
> > While testing my output table memory patch in your nse-lua-merge branch
> > I ran into what appears to be a deadlock.  When I turn on packet
> > tracking (runtime interaction) nothing is being sent or received.
> >
> > I noticed that there is (new?) output listing the number of script
> > waiting:
> >
> > Stats: 1:56:29 elapsed; 370 hosts completed (120 up), 1 undergoing Script Scan
> > NSE: Active NSE Script Threads: 30 (30 waiting)
> >
> > I assume this means that I've run into a deadlock.  I've done a heck of
> > a lot of testing in this branch and this is the first time I've seen a
> > deadlock like this so I assume the conditions to cause it are pretty
> > involved.
>
> This is a symptom of the failing nsock library binding which has
> plagued NSE with bugs for a while now. That it happened in
> nse-lua-merge is merely happenstance. In the future I hope to clean it
> up like I did with the nmap library.

So, if I understand correctly, this problem could have happened with NSE
in the trunk too? If so then it is not a barrier to merging.

Can you explain more fully the nature of this problem? In the
nse-lua-merge branch you have added to the Nsock userdata an array that
indirectly holds the arguments to receive_buf:

struct l_nsock_udata {
        ...
        int rbuf_args[3]; /* indices in lua registry for receive_buf args */
        ...
};

In the nse-lua branch you have fuller support for that kind of thing.
Can you explain why that is necessary, and why leaving the values on the
stack, as is done now, doesn't work?

David Fifield

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