Re: Socket troubles: Too many open files

[David Fifield <david () bamsoftware com>]

On Fri, Sep 21, 2012 at 07:26:41AM -0400, Patrick Donnelly wrote:
> On Fri, Sep 21, 2012 at 3:09 AM, David Fifield <david () bamsoftware com> wrote:
> > On Thu, Sep 20, 2012 at 10:08:33PM -0400, Patrick Donnelly wrote:
> > > On Thu, Sep 20, 2012 at 9:23 PM, David Fifield <david () bamsoftware com> wrote:
> > > > The descriptors created in the first four calls would be lost, and only
> > > > the last would be reclaimed by the close. I think this is a bug in Nsock
> > > > or in the NSE binding to Nsock.
> > >
> > > I think the problem was introduced when the nsock binding moved socket
> > > iod allocation from new_socket to connect (which was a good thing). I
> > > don't know if throwing a `if (nu->nsiod == NULL) nu->nsiod =
> > > nsi_new(nsp, NULL);' is the right fix...
> >
> > Good thought, but I get this error:
> >
> > NSOCK (0.2220s) TCP connection requested to 127.0.0.1:1000 (IOD #1) EID 8
> > NSOCK (0.2720s) Callback: CONNECT TIMEOUT for EID 8 [127.0.0.1:1000]
> > NSE: TCP 127.0.0.1:36140 > 127.0.0.1:1000 | CONNECT
> > NSOCK (0.2720s) TCP connection requested to 127.0.0.1:1000 (IOD #1) EID 16
> > Unable to update events for IOD #1: No such file or directory
> > QUITTING!
> > NSE: TCP 127.0.0.1:36141 > 127.0.0.1:1000 | CLOSE
> > NSOCK (0.2720s) nsi_delete (IOD #1)
> > Trying to delete NSI, but could not find 1 of the purportedly pending events on that IOD.
> >
> > QUITTING!
> >
> > What do you think about this patch? It moves some common code to a
> > close_internal function, then calls close_internal when connect is
> > called again on an already initialized socket. We don't call initialize
> > again, because that discards socket data like the timeout.
>
> Looks good to me. Maybe also add a trace event message and/or a debug
> message that the socket is being closed due to a new (re)connect on
> the socket?

I moved the trace message to be shown in both cases and committed in
r29845.

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