Re: beep file descriptors not being closed

Thanks Bill,

The transport layer does make a call to function shutdown_callback()
in file threaded_os/wrapper/bp_wrapper.c. I modified the following
code fragment (around line 2020)
....
else if (wrap->conn.status == INST_STATUS_EXIT) {
        fiostate_delete(wrap->iostate);
        wrap->iostate = NULL;
    } else ....

and changed it to
....
else if (wrap->conn.status == INST_STATUS_EXIT) {
        int fd = wrap->iostate -> socket;
        fiostate_delete(wrap->iostate);
        wrap->iostate = NULL;
        close(fd);
    } else ....

This seems to have fixed the problem. As to the validity of this
fix I can't say but further down the function their are some
'/** @todo fix this... */' comments so i hope to do some more
investigation when I've time.

Andy


"William J. Mills" wrote:
> 
> Hmmmm....  Well the accept is done  up pretty high as I remember
> and I am not sure that top level loop will ever get a notification
> on the close, though it might on the destruction of the wrapper.
> 
> I'd say that the same code that initiates the transport layer should
> colse the socket or the transport layer itself should hanlde the close
> it is detected, or when the transport cleanup/destructor is called.
> 
> So, look in the wrapper destroy function, and I cant remember the
> transport shutdown function name...
> 
> Does this help you get oriented?
> 
> -bill
> 
> On Wed, Dec 18, 2002 at 06:23:23PM +0000, Andy Walshe wrote:
> > Hello,
> > I have found an issue regarding file descriptors in beep.
> >
> > The beepd listener makes a call to accept() and a corresponding
> > call to close() is not made for the file descriptor.
> >
> > The problem can be seen by running the example programs as follows:
> > 1. start the beepd listener as follows:
> >     >> truss -o truss.out -t open,creat,close,so_socket,accept
> >                                                   beepd -f beepd.cfg
> > 2. run the sample initiator beepng. e.g.
> >     >> beepng -a testing -f beepng.cfg -m echo -p 10289 server_name
> > 3. tail the output file in another window
> >     >> tail -f truss.out
> >
> > You will see something like the following (if you run the sample
> > initiator 4 times)
> > ......
> > open("/usr/local/lib/libnull-profiles.so", O_RDONLY) Err#2 ENOENT
> > open("/usr/local/lib/python2.2/libnull-profiles.so", O_RDONLY) Err#2
> > ENOENT
> > open("/vobs/3p/openssl-0.9.6g/lib/libnull-profiles.so", O_RDONLY) Err#2
> > ENOENT
> > open("/vobs/3p/beepcore-c-0.2/Release/lib/libnull-profiles.so",
> > O_RDONLY) = 5
> > close(5)                    = 0
> > so_socket(2, 2, 0, "", 1)           = 5
> > accept(5, 0x00000000, 0x00000000, 1)        = 6
> > accept(5, 0x00000000, 0x00000000, 1)        = 7
> > accept(5, 0x00000000, 0x00000000, 1)        = 8
> > accept(5, 0x00000000, 0x00000000, 1)        = 9
> >
> >
> > I had a go at closing the file descriptor in pro_close_confirmation()
> > in my profile but this hung the listener (it seems it still uses the
> > file descriptor).
> >
> > I presume the beepcore-c library should close this fd and am
> > investigating it but ain't too familiar with the code. Any pointers
> > or solutions appreciated.
> >
> >
> > Andy
> >
> >
> > -------------------------------------------------------
> > This SF.NET email is sponsored by: Order your Holiday Geek Presents Now!
> > Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap,
> > MP3 Players,  XBox Games,  Flying Saucers,  WebCams,  Smart Putty.
> > T H I N K G E E K . C O M       http://www.thinkgeek.com/sf/
> > _______________________________________________
> > Beepcore-c-users mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/beepcore-c-users


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com